Lazarus

Miscellaneous => Suggestions => IDE/CodeTools => Topic started by: ertank on July 19, 2017, 11:05:59 pm

Title: Keeping track of project statistics - timings
Post by: ertank on July 19, 2017, 11:05:59 pm
Hello,

I would love to see a functionality which recent versions of Delphi has (please see attached picture). It would be sufficient to have some of them as a starter.

I have no experience with Lazarus code myself. I might be a semi-volunteer (because my Pascal skills are not expert), but I don't even know where to look. It would be nice to have information of Project total time, Editing time as a starter.

It may be added design time, debug time etc later.

Of course, it has to be decided where these information will be saved. In a new file? (Delphi is doing it this way) or, in project file itself?

I event do not know if this forum is the right place to fire that post.

Thanks & regards,
Ertan
Title: Re: Keeping track of project statistics - timings
Post by: Martin_fr on July 20, 2017, 12:58:48 am
Of course, it has to be decided where these information will be saved. In a new file? (Delphi is doing it this way) or, in project file itself?

Sounds like the could go into project session. (lps file)
Same like which file is open in which editor.
Title: Re: Keeping track of project statistics - timings
Post by: tr_escape on July 20, 2017, 06:48:55 am
Actually maybe GIT integration is will be good for Lazarus but as you know if you don't commit your changes/codes to GIT or other versioning or work/project trackers can't help you.

Delphi has got a history system but as I know not working on form design , however if you save all of your changes into a history database your project size will be incrase.

Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 07:35:55 am
This feature is relatively easy to implement but is it worth it? I see in the screenshot "Editing Time". What if Lazarus is open, the editor is in focus, but I'm away for a coffe break. Still considered editing? Or should I start a timer after the last keystroke? What if I'm adding 100 icon to my project with the mouse? Still considered editing right? Hook the mouse? What is "Other"? So many questions...
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 09:02:44 am
This feature is relatively easy to implement but is it worth it? I see in the screenshot "Editing Time". What if Lazarus is open, the editor is in focus, but I'm away for a coffe break. Still considered editing? Or should I start a timer after the last keystroke?
No you start a timmer on the application Idle and when it passes a threshold eg 10 seconds you stop counting editing if a key is pressed inside that time you reset the timer.
What if I'm adding 100 icon to my project with the mouse? Still considered editing right? Hook the mouse? What is "Other"? So many questions...
No this is considered design time.
Hook the mouse?
No same concept while the designer is on top of the editor and the application on idle has never passed a threshold period then it counts as design time. If there was a UML designer included then we could split hairs about what type of design although it would be a subgroup of the design group also.
What is "Other"? So many questions...
well for now edit/design/admiring are the 3 that need to be done :P
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 09:26:56 am
@taazz
Still too many inconsistencies...What if the editor is in focus, then when I come back I click the main menu. I can imagine at least ten scenarios when it would be extremely difficult to decide what time goes where.

Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 09:43:52 am
@taazz
Still too many inconsistencies...What if the editor is in focus
the the idle timer will have kicked in and stopped the time counter.

, then when I come back I click the main menu. I can imagine at least ten scenarios when it would be extremely difficult to decide what time goes where.
a new time counter begins or not depending on where you click and waits for you next move or the idle timer's end value.
I can imagine at least ten scenarios when it would be extremely difficult to decide what time goes where.
Yeah I can imagine even more, but the fact is that the counters time one thing and one thing only, how much time you spend interacting with the IDE and which parts of it. Nothing more. You can write a small program that feeds the active window with a key stroke every second lets say "a" and "backspace" in sequence leave the IDE focused go out for vacation and return and have a two weeks non stop editing. what of it?
Title: Re: Keeping track of project statistics - timings
Post by: josh on July 20, 2017, 09:54:41 am
WHat about creating application in a team?
Ideally it would need to keep a track of individual users/pc's time, and also a time on which files/units have been changed in the case of shared files.
 
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 10:03:11 am
WHat about creating application in a team?
Ideally it would need to keep a track of individual users/pc's time, and also a time on which files/units have been changed in the case of shared files.
NO. the Ide can not and should not know anything about a team or a user. it can post the timing values to a server along with the logged in user name and that's it anything else is outside the scope of the IDE. How those data are presented/interpreted etc is a matter of an other application. The IDE is only harvesting times.
Title: Re: Keeping track of project statistics - timings
Post by: Thaddy on July 20, 2017, 10:13:49 am
NO. the Ide can not and should not know anything about a team or a user. it can post the timing values to a server along with the logged in user name and that's it anything else is outside the scope of the IDE. How those data are presented/interpreted etc is a matter of an other application. The IDE is only harvesting times.
I totally disagree with that. In a team an advanced (not notepad) IDE should and must support the team. Usually that is done by supporting version control. (who is working on what?, which file is locked (and why and by whom) , what do I need to merge?. An advanced IDE is not only harvesting, it is communicating both ways with a team.

Note that metrics in general are only useful if you interpret them right. Timing is one of the easiest to implement but then again also one of the less useful metrics.
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 10:15:49 am
@taazz
With your last 2-3 posts, basically you auto-assigned yourself to implement this feature.  :D
Title: Re: Keeping track of project statistics - timings
Post by: Thaddy on July 20, 2017, 12:34:21 pm
+1  :D (that's my first...ever...)
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 12:36:55 pm
@taazz
With your last 2-3 posts, basically you auto-assigned yourself to implement this feature.  :D
OK. I'll put it in my long list of volunteering work I have to finish. Let me see, I'm working on turbobird this is #1, I have the simplegraph to polish this is #2, a small tpagecontrol replacement with custom tab design (a working prototype with attabs as the tabset is finished and part of turbobird's next release) that's #3, The conversion of the KWizard (if memory serves me right) that I promised some one in this forums I'll finish up that's #4, Oh yeah juhas request (more than a recommendation than request) to port a scripting IDE to lazarus #5, extensions to code librarian for net collaboration #6, the work I started on NewACS to port to lazarus/linux and beyond that's #99 (too low in my list), code librarian and turbobird addins for lazarus #98, Ok i'll jam it somewhere in between those how about  #10? Is this acceptable?
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 12:50:19 pm
Let's see what the core developer says about this feature. If we got green light, I will implement it, but we need to lay down the rules before. Sill many parts are not clear to me. 
Title: Re: Keeping track of project statistics - timings
Post by: Martin_fr on July 20, 2017, 01:06:38 pm
IMHO it should be done a package.
It may be that it will go to Lazarus CCR. (but lets see what others say)

The question is which info the package needs to get from the IDE, and if the units in IDEInf can provide this, or what hooks needs to be added there.
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 02:58:54 pm
IMHO it should be done a package.
It may be that it will go to Lazarus CCR. (but lets see what others say)
I agree it should an external package. but not CCR. CCR is where component go to die or at least that is how I see it.

The question is which info the package needs to get from the IDE, and if the units in IDEInf can provide this, or what hooks needs to be added there.
actually the info required are minimal focus changed to designer/editor/object inspector/debug windows etc, debugging started/ended (either normally or by resetting it), application.idle, focused, lost focus etc. and the package will have its own api that others can use.
Title: Re: Keeping track of project statistics - timings
Post by: Martin_fr on July 20, 2017, 03:13:26 pm
actually the info required are minimal focus changed to designer/editor/object inspector/debug windows etc, debugging started/ended (either normally or by resetting it), application.idle, focused, lost focus etc. and the package will have its own api that others can use.

SourceEditorIntf afaik has an event that can trigger on focus, and on any change (including scroll and caret) to detect activity (except: staring at code in disbelieve)

Not sure about the others.
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 04:03:24 pm
actually the info required are minimal focus changed to designer/editor/object inspector/debug windows etc, debugging started/ended (either normally or by resetting it), application.idle, focused, lost focus etc. and the package will have its own api that others can use.

SourceEditorIntf afaik has an event that can trigger on focus, and on any change (including scroll and caret) to detect activity (except: staring at code in disbelieve)

Not sure about the others.
Taking advantage of the static linking nature of fpc the application.addXXXXXhandler can be used to support application changing from a package, assuming that the forms units and the application in there is used from the IDE it self. The Screen.OnActiveFormChange event can be used to monitor changes between forms inside the IDE. That leaves the start/stop debugging.
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 04:23:19 pm
Thanks @Martin_fr, @Taazz for the feedback. I already started developing the package. Few details:
1. The package name is ProjectStatistic.lpk
2. It will be part of the Online Package Manager not CCR. Every major package from CCR is already ported to OPM
3. After install it can be accessed through Lazarus Menu-->Project-->Project Statistics(Ctrl + Shift + F12), just below project option(see attached image)
4. The timing is done with a worker thread
5. The statistics is loaded/saved from/to the *.lpi file
6. After a few short test, I was able to hook both the sourceeditor and the designer. The question is what happens when the main form is in focus(where the menu and component palette is) or the object inspector or any other window? In which timing category falls the main window?
7. Apparently it's possible to implement everything from the package itself, without changing the IDE source or IDEintf
8. What about Copyright infringement if any? Is this feature patented?
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 04:46:15 pm
Thanks @Martin_fr, @Taazz for the feedback. I already started developing the package. Few details:
1. The package name is ProjectStatistic.lpk
2. It will be part of the Online Package Manager not CCR. Every major package from CCR is already ported to OPM
3. After install it can be accessed through Lazarus Menu-->Project-->Project Statistics(Ctrl + Shift + F12), just below project option(see attached image)
4. The timing is done with a worker thread
5. The statistics is loaded/saved from/to the *.lpi file
erm no lpi is usually under source control. For now it should use its own file, based on the active project of course.
6. After a few short test, I was able to hook both the sourceeditor and the designer. The question is what happens when the main form is in focus(where the menu and component palette is) or the object inspector or any other window? In which timing category falls the main window?
both/none if the focused is changed to the menu/toolbar/component palette window then no action should be taken the existing 1st level windows keeps on time tracking. OBject inspector is probably safe to group it with the designer.
7. Apparently it's possible to implement everything from the package itself, without changing the IDE source or IDEintf
as long as it remains statically linked?
8. What about Copyright infringement if any? Is this feature patented?
This is better left for the team to answer. (that was quick!)
Title: Re: Keeping track of project statistics - timings
Post by: JuhaManninen on July 20, 2017, 08:31:47 pm
Oh yeah juhas request (more than a recommendation than request) to port a scripting IDE to lazarus
Sounds like a good idea although I have forgotten what it was about.

This timing statistics feature sounds good, too.
I personally miss a project metrics feature even more. It is also statistics but about the code already created instead of time.
Lines of code, amount of comments, maybe some code quality analysis, etc.
Codetools provide most tools to implement it I guess.
Anyway, it does not compete with the feature you are planning now. They are both usefull.
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 08:59:09 pm
@taazz
I sent a mail to devlist, let's see what they say about this feature.

@Juha
Quote
This timing statistics feature sounds good, too.
I personally miss a project metrics feature even more. It is also statistics but about the code already created instead of time.
Lines of code, amount of comments, maybe some code quality analysis, etc.
Codetools provide most tools to implement it I guess.
Anyway, it does not compete with the feature you are planning now. They are both usefull.
Good idea! I will implement the timing first, then we can add more and more feature. I also have to implement the OPM integration, but I need to build up some courage first, it's really complicated, time consuming stuff. :D
Title: Re: Keeping track of project statistics - timings
Post by: avra on July 20, 2017, 09:08:46 pm
I look at project stats in a slightly different way. I find it useful if it can provide me enough data to bill a customer for contract work. It would also mean using separate XML, JSON, CSV or whatever instead of LPI file (of course also stored in project dir). It should be enabled per project (default off), and on each project exit it should simply add a new record with updated time for each stats category. This would allow using custom external tools for creating bills, creating internal report, and allow team work where each member would have his own stats file (excluded from version control system of course). I do not think that using a timer to detect idle work is a good idea. There should be no idle work when I open such a project. What if I look 10 minutes at some code trying to understand without using mouse and keyboard at all? It should be much simpler. If specific windows are opened then specific categories get their time updated. If Lazarus window is not focused then some 'Other' category gets it's time updated. If focused app name is logged then custom external tool (or a patch from interested party) could further refine stats for 'Other' category (if anyone would need such refinement).
Now please be gentle and don't shoot me (at least not in the head)  ;D
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 20, 2017, 09:13:33 pm
Oh yeah juhas request (more than a recommendation than request) to port a scripting IDE to lazarus
Sounds like a good idea although I have forgotten what it was about.
As it turns out I was a bit confused, but here is the thread that started me down the ide conversion road http://forum.lazarus.freepascal.org/index.php/topic,19225.msg139911.html#msg139911 (http://forum.lazarus.freepascal.org/index.php/topic,19225.msg139911.html#msg139911)
Still on my list I'll eventually convert it and post it on SF. I just need to clean up my more argent tasks first.
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 20, 2017, 09:43:12 pm
@avra
Thanks for the feedback.

Quote
I look at project stats in a slightly different way. I find it useful if it can provide me enough data to bill a customer for contract work. It would also mean using separate XML, JSON, CSV or whatever instead of LPI file (of course also stored in project dir). It should be enabled per project (default off), and on each project exit it should simply add a new record with updated time for each stats category. This would allow using custom external tools for creating bills, creating internal report, and allow team work where each member would have his own stats file (excluded from version control system of course).
It will be the lps or some other external file, xml most likely. 

Quote
I do not think that using a timer to detect idle work is a good idea. There should be no idle work when I open such a project. What if I look 10 minutes at some code trying to understand without using mouse and keyboard at all? It should be much simpler. If specific windows are opened then specific categories get their time updated. If Lazarus window is not focused then some 'Other' category gets it's time updated. If focused app name is logged then custom external tool (or a patch from interested party) could further refine stats for 'Other' category (if anyone would need such refinement).
Now please be gentle and don't shoot me (at least not in the head)  ;D
@taazz already came up with a good idea. Start a timer on application idle, then after a predefined number of seconds stop the log. I'm still not sure about that categories though. Which window has focus it's not a problem, it will be easy to detect.
Title: Re: Keeping track of project statistics - timings
Post by: ertank on July 20, 2017, 10:18:47 pm
8. What about Copyright infringement if any? Is this feature patented?

I could not find anything in between Delphi Acknowledgements lines.
I could not find any patent or copyright for Castalia statistics which is taken by Embarcadero
See:
https://www.embarcadero.com/press-releases/embarcadero-acquires-castalia-and-usertility-from-twodesk-software
http://blog.marcocantu.com/blog/2014_september_free_castalia_xe7.html
http://blog.marcocantu.com/blog/2015-january-embarcadero-acquires-castalia-usertility.html

I would say it is a proprietary code for Delphi/C++ Builder IDE and we are dealing with Lazarus IDE here. So, I presume there is no copyright problem here.
Title: Re: Keeping track of project statistics - timings
Post by: avra on July 20, 2017, 10:26:24 pm
It will be the lps or some other external file, xml most likely.
LPS is fine if you do not store history, but if you always add a record on each project exit then it can groooow. So I vote for separate file. It looks cleaner to me.

Quote
Start a timer on application idle, then after a predefined number of seconds stop the log.
Well if that number of seconds can be a zillion, in practice that would not differ from my idea to not allow idle time.  :)

Quote
I'm still not sure about that categories though. Which window has focus it's not a problem, it will be easy to detect.
This is one of possibilities for categories:

Category      Window/AppName         Time                       SumOfSeconds
============================================================================
Lazarus       Object Inpector        2012-04-23T18:25:43.511Z   2411
Lazarus       Form Designer          2012-04-23T18:25:43.511Z   825
Lazarus       Code Editor            2012-04-23T18:25:43.511Z   5432
Other         Photoshop              2012-04-23T18:25:43.511Z   1042
Lazarus       H2Pas                  2012-04-23T18:25:43.511Z   3119
Other         Notepad++              2012-04-23T18:25:43.511Z   753


In simple variant categories are not needed at all. Who needs them let him build external tool. In more complex variant you can have somewhere stored a list of Lazarus specific Window/AppName and flag them as 'Lazarus' category. Everything else can be 'Other' category.

Having an option not to save stats for windows which were active for less then some user chosen number of seconds would filter out irrelevant records.
Title: Re: Keeping track of project statistics - timings
Post by: JuhaManninen on July 20, 2017, 11:21:14 pm
I could not find any patent or copyright for Castalia statistics which is taken by Embarcadero
Measuring time cannot be patented I hope. It would make many people's life difficult.

Quote
I would say it is a proprietary code for Delphi/C++ Builder IDE and we are dealing with Lazarus IDE here. So, I presume there is no copyright problem here.
Exactly.
Title: Re: Keeping track of project statistics - timings
Post by: ertank on July 21, 2017, 01:05:13 am
Also, I appreciate considering different operating systems. On my part, I am mostly using Lazarus on Raspberry Pi recently. It may not be so easy to collect "other software usage" statistics in there. On the other hand, I do really wonder what percentage will be compile timing in there  :)
Title: Re: Keeping track of project statistics - timings
Post by: avra on July 21, 2017, 10:23:56 am
I am mostly using Lazarus on Raspberry Pi recently. It may not be so easy to collect "other software usage" statistics in there.
I do not see how would that differ to other Linuxes. Whenever Lazarus is not focused that can be 'Other' category, having or not having a subcategory with window title. That way it's not hard to filter out what info is not needed for internal or external stats presentation.
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 21, 2017, 10:48:51 am
I am mostly using Lazarus on Raspberry Pi recently. It may not be so easy to collect "other software usage" statistics in there.
I do not see how would that differ to other Linuxes. Whenever Lazarus is not focused that can be 'Other' category, having or not having a subcategory with window title. That way it's not hard to filter out what info is not needed for internal or external stats presentation.
No, that is asking too much this is an IDE addin  not a general time tracking application. It suppose to help you understand where most of your time is spend inside the IDE. There are general time tracking application out there use one of those if you want something more.
Title: Re: Keeping track of project statistics - timings
Post by: avra on July 21, 2017, 11:43:47 am
It suppose to help you understand where most of your time is spend inside the IDE.
So everything outside of IDE is 'Other'. Good enough for me to make a patch that would differentiate further if needed. No one would be forced to use automated time tracking if he doesn't want to. However I am quite sure I wouldn't be the only user of such a feature.
 ::)
Title: Re: Keeping track of project statistics - timings
Post by: Thaddy on July 21, 2017, 11:55:31 am
8. What about Copyright infringement if any? Is this feature patented?

Well actually they were patented at some point by AT&T Bell Labs (metrics, 1955, before I was born 1958). But the patents expired a very long time ago and were - with hindsight - probably never valid because of prior knowledge: it is a very minor subset of statistics.

https://en.wikipedia.org/wiki/Bell_Labs More specific by Bob Prim.
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 21, 2017, 12:01:47 pm
It suppose to help you understand where most of your time is spend inside the IDE.
So everything outside of IDE is 'Other'. Good enough for me to make a patch that would differentiate further if needed. No one would be forced to use automated time tracking if he doesn't want to. However I am quite sure I wouldn't be the only user of such a feature.
 ::)
I was thinking more on the lines of Idle time but you can name it other if you wish.
Title: Re: Keeping track of project statistics - timings
Post by: Thaddy on July 21, 2017, 12:06:22 pm
I was thinking more on the lines of Idle time but you can name it other if you wish.
You should be thinking in terms of goals.
IDE means Integrated Development Environment. Which basically says it all: a set of functionality geared towards producing - in this case- software.
Avra is right. For a user, this integration is and should be completely opaque.
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 21, 2017, 12:16:22 pm
Ok. The skeleton is ready. Don't get too excited, this is just the beginning.

1. Install projectstatistic.lpk
2. Open the main form: Lazarus Menu-->Project-->Project statistics(the form style is StayOnTop for now)
3. Please try to click between different lazarus form(editor, designer, etc) and see what happens. Wait 10 seconds to trigger the idle.
4. Test it without a docking manager(sparta, etc...)

Feedback is welcome.

Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 21, 2017, 12:23:32 pm
just a small clarification. I'm not here to dictate policy, goals, or use cases on someone else work/time. What ever is posted here is an opinion based on my guidelines of software development. And I feel strongly that by extending the app beyond the IDE we are breaking one of the basic rules, something along the lines of, only do one job and don't try to be everything for everyone. Since this is not my time or my code I can only be thankful for what ever getmem decides to share. So to avoid me getting out of line I'll simple stop repeating my self.
Title: Re: Keeping track of project statistics - timings
Post by: ertank on July 21, 2017, 12:31:37 pm
Ok. The skeleton is ready. Don't get to excited is just the beginning.

1. Install projectstatistic.lpk
2. Open the main form: Lazarus Menu-->Project-->Project statistics(the form style is StayOnTop for now)
3. Please try to click between different lazarus form(editor, designer, etc) and see what happens. Wait 10 seconds to trigger the idle.
4. Test it without a docking manager(sparta, etc...)

Feedback is welcome.

How should we get the package? SVN trunk? Download link?
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 21, 2017, 12:45:32 pm
@avra, @thaddy
I'm not gonna log anything outside the IDE, it makes no sense. I mean if the user watch some p@rn between two programming session we should log in in the lps file? Wtf?  :D
Just to be clear: for now "other" means not editing and not designing.

@ertank
Attached to my previous post. Is just the skeleton, so don't get too excited.
Title: Re: Keeping track of project statistics - timings
Post by: taazz on July 21, 2017, 01:40:19 pm
A couple of quick comments.

1) object inspector is grouped in other, it should be grouped in designer. well grain of salt and all that.
2) main menu is grouped in other as well it should not change the group use the last active group.
3) It does not recognizes at all changing to an application outside lazarus and only the time out kicks in. It has a small after effect that if your other application is not maximized every time the mouse passes over the editor it registers as editing time although lazarus is not focused.

I like the idea of registering the form name as well as long as it gets in the data, regardless of grouping.
Title: Re: Keeping track of project statistics - timings
Post by: ertank on July 21, 2017, 02:56:38 pm
Ok. The skeleton is ready. Don't get too excited, this is just the beginning.

1. Install projectstatistic.lpk
2. Open the main form: Lazarus Menu-->Project-->Project statistics(the form style is StayOnTop for now)
3. Please try to click between different lazarus form(editor, designer, etc) and see what happens. Wait 10 seconds to trigger the idle.
4. Test it without a docking manager(sparta, etc...)

Feedback is welcome.

My initial feedback.

First of all thank you for this real fast design.

1- I suggest mouse move should not be considered as active. Just clicks. When I click a form or Edit window status can be active.

Reason: I am working on my editor. I stop working on it. It turns as Idle. I move my mouse to my browser and it is active again because it has to go over editor window to reach browser window. I am not doing anything on IDE though.

2- When Idle triggers, would be nice to reduce (last timing - Idle delay timing) in order to have correct calculation as 10 seconds will pile up and may even make hours overall.

Other than this, I see its operational and ready for summing up seconds :)

Thank you.
Title: Re: Keeping track of project statistics - timings
Post by: Thaddy on July 21, 2017, 02:57:19 pm
I'm not gonna log anything outside the IDE, it makes no sense. I mean if the user watch some <s3ns0r3d: favorite hbo series to your liking> between two programming session we should log in in the lps file? Wtf?  :D
I mean even worse... logging on the network.... In a team that is functional. I even introduced it many times... Just for code, not for web/email/private things.
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on July 23, 2017, 08:49:22 am
Hi all,

Thanks for the feedback and sorry for the late reply, I was out in the wild with no internet connection.

@taazz
Quote
1) object inspector is grouped in other, it should be grouped in designer. well grain of salt and all that.
Quote
2) main menu is grouped in other as well it should not change the group use the last active group.
Quote
3) It has a small after effect that if your other application is not maximized every time the mouse passes over the editor it registers as editing time although lazarus is not focused.
Fixed.


@ertank
Quote
1- I suggest mouse move should not be considered as active. Just clicks. When I click a form or Edit window status can be active.
Fixed.

Quote
2- When Idle triggers, would be nice to reduce (last timing - Idle delay timing) in order to have correct calculation as 10 seconds will pile up and may even make hours overall.
I changed to 2 seconds, it will be configurable in the future.



@Thaddy
Quote
I mean even worse... logging on the network.... In a team that is functional. I even introduced it many times... Just for code, not for web/email/private things.
Ok. Linking two or more Lazarus IDE for a team project make sense, but then you need a server and the implementation would require a lot of work. I'm not against it, but I'm not gonna implement it, at least not in the near future.

PS: As time permits, I will continue the development and report back. Thanks again for the feedback.
Title: Re: Keeping track of project statistics - timings
Post by: valdir.marcos on April 24, 2018, 11:57:07 pm
Just curious.
Is this project finished?
Title: Re: Keeping track of project statistics - timings
Post by: GetMem on April 25, 2018, 05:29:27 am
Quote
Just curious.
Is this project finished?
Unfortunately no. You can find the latest version as attachment in reply #42. It shouldn't be to hard to complete though, if somebody has the free time.

PS: If sparta/anchordocking is installed, some fake form are created and it's much harder to differentiate between design time and editing time(see first post for requirement),  this is the only drawback I found.