|
Great!
|
|
|
|
|
I have a class library for ToDoList in C#. And I have a little test routine that reads a .tdl, loops through nested tasks and displays some properties. My next challenge is to ensure that updates don't trash the .tdl XML and that all data is saved with proper typing, etc.
Anyone can do this really. It was very easy to create this using the XSD command-line utility to generate both a set of strongly typed classes as well as a DataTable class for ORM, MVC, and apps that require a datasource. I'm just wondering if a project should be made of it. Because TDL changes and once in a while the schema of the XML may change as well, the library shouldn't be customized much itself. We should be able to regenerate a base set of classes quickly.
But then around that I'm thinking a set of extensions can be created to do various things with the data. This might include mass changes, automated replication of task structures, exchanges with other applications, using TDL as a data source for trackers or time keeping systems, or dare I say, perhaps even building a web-based version of TDL where the resulting data can be opened by anyone who has TDL itself installed.
So if anyone has suggestions for this I'll see what I can do to create a little library and I'll publish it as FOSS along with documentation on how to create and replace the underlying classes.
I'll add some more notes here soon with a couple code examples to give you an idea of how it works.
(Tagging this post with reference to ToDoListLibDotNet)
modified 10-Feb-14 2:04am.
|
|
|
|
|
iamstarbuck wrote: So if anyone has suggestions for this I would love to see a decent Report Writer for TDL, though I suspect that a mobile/web interface would probably be highest on many people's lists.
And if that could be integrated with DropBox/Google Drive/SkyDrive then we would have a major winner!
Though it would have to be a cut down version to make sure people kept using the desktop version
|
|
|
|
|
With a dataset defined we can make use of various report writers. I have an idea in mind and will come back to it.
There's no way I'd try to emulate the full functionality of the desktop version with a browser UI. (Perhaps someone else might try but we'll leave that to the future.) And as with any utility based on some platform, it will always require maintenance to keep up with the "core". I supposed this is where the Android version is and will always be.
Anyway, I now have a full wrapper class for a task, and resulting from the effort I have updates to the todolist_xml_schema.txt file that I'll email for your checking.
I ran into a small roadblock: The todolist_schema.xsd that comes with the package defines the list of tasks within a task as xsd:anyType. So when I deserialize I get a ToDoList with Tasks, and in a Task with subtasks I get an object array of XML Nodes ...because it has no idea what to do with them. I'm guessing that xsd is just old. I generated my own xsd from a .tdl file and it does have TASK including a sequence of TASK elements.
If I generate my own xsd I'm going to miss nuances that are not in the specific .tdl being used. I'd like to be able to regenerate all of the underlying code using a .xsd that comes with the software. Is this something you'd like to do or should I generate an xsd which is as complete as I think as I can get it and then we can use that as a base from this point forward?
Thanks.
|
|
|
|
|
An .xsd is only going to do you any good if Dan promises to adhere to it. Which from what I've seen I don't think he's prepared to do.
From what I have seen I don't believe Dan loads the data dictionary / .xsd with the .dll msxsl calls, and to do so now will involve a fair bit of work, and a non-trivial amount of grief.
e.g. Suppose this were implemented ... at each file load TDL will have to check for a prior or no schema used, and react accordingly. By field even. Which means an extraordinary amount of error handling to deal with elements found that don't adhere to any spec.
The one thing I can think of that may help would be to embed the xsd within the .tdl. Then TDL can work with whatever form the data is in, no matter what version of TDL was used to create it.
With a 'rewrite file to current schema' button, later feature adds could then be taken advantage of - at the expense of backwards compatibility, which may be livable.
But each data call within TDL would have to start prefixing everything with something like 'if meta element exists, process meta element'.
|
|
|
|
|
iamstarbuck wrote: should I generate an xsd which is as complete as I think as I can get it and then we can use that as a base from this point forward? This please.
|
|
|
|
|
Do we not already have a mobile interface in TDL ToDoList at https://play.google.com/store/apps/details?id=hg.hgTdlList&hl=en ?
And it's so well on it's way that reinventing that wheel seems counter-intuitive?
And do we not already have DropBox/GoogleDrive/SkyDrive, it's just a particular replicated directory from the local computer?
- if there are current problems with DropBox, do please let me know - I'm trying to wrap things up to put a TDL / Dropbox solution into production, so would appreciate any heads up.
Not knowing Android, by any chance, is there a way to leverage that app into a google/chrome app and you have a web interface?
As I understand it, it can read Google Drive, but not write. I expect that is a limitation of Google Drive / additional coding effort. Don't know anything about Skydrive other than it can replicate.
What you really want is record and field locking - then it doesn't matter who's accessing the file simultaneously, and no DropBox/GoogleDrive/SkyDrive is ever going to deliver that. It also presumes disparate GUI's and DBMS', such as a web interface talking to that DBMS back end while the TDL GUI is doing the same, and we're back to ground zero again. Let alone all current clients at the time receiving record/field change notifications.
|
|
|
|
|
The only wheel that's being re-invented (and in a good way) would be that the Android app provides some of the same functionality as the desktop app, but by far not all features. Just because Android apps are written in Java doesn't mean they're anywhere near ready for deployment in a web browser or desktop. The UI code and other internals are so fundamentally different between the mobile UI and a browser or desktop UI that a completely different app would be required for each.
I know very little about Google Driver, etc, can't comment.
As to record locking however, any app that is designed to update the .tdl file must not lock the file. If ToDoList itself does this then one would not be able to run TDL and another app simultaneously, or each app would require a mechanism to re-read the file as required. I think this is a bridge we can cross when we get to it. There are a variety of solutions possible.
|
|
|
|
|
> the Android app provides some of the same functionality as the desktop app, but by far not all features.
Just a thought, but doesn't that mean your time may be better spent helping on the Android app? (Particularly as it could more easily be leveraged to other platforms?)
> Just because Android apps are written in Java doesn't mean they're anywhere near ready for deployment in a web browser or desktop
Which says to me rewrite in java?
I would guess that a browser java app, a desktop java app, an android java app, and a chrome java app are all far closer than many other things. Particularly as common / cross-platform libraries would get called in as appropriate for each environment, by that environment?
I don't believe these end up being different apps, and share a common code base.
The claim to date is speed. Given what you say, if you're going to change languages, for the largest audience possible, it sounds like you should be writing in java next. If speed is indeed an issue given today's devices and java advancements vs the time when TDL was first conceived, and mechanisms to improve things are demonstrated as being insufficient, then and only then move on to something else? The very act of going to java should inherently streamline the logic.
> As to record locking however, any app that is designed to update the .tdl file must not lock the file
File locking is already in play. I don't remember the last time I tried - but two instances on the same file is going to make one or the other unhappy, IIRC.
Checking the file out causes locked to go in TODOLIST, rendering each additional instance read only.
The mechanism to re-read the file is already necessary. By definition you are at that bridge right now - if I'm in the gui then run your code ... where there. This is basic / built in to TDL.
|
|
|
|
|
Going backwards here and starting with file locking. I'd like Dan's comments. If another app can't operate on the XML data while TDL is up, then we'll need some way for another app to gracefully terminate TDL and then restart it. I don't like that at all. Would be better to set a flag somewhere that asks TDL to release its lock, and then use another flag to tell TDL that it needs to refresh a .tdl file before continuing.
As to a rewrite in Java. This is far beyond the scope of my effort. You need to separate the concepts of a helper library from an application. Right now I'm trying to make it easy for .NET developers to access TDL. I'm not working on a new UI, cross-platform compatibility, or any specific application. I also work with Java, and I do Android apps, but my personal goal with TDL is not oriented in that direction yet. So if someone else wants to do what I'm doing in Java, great, I'll even collaborate with them so that we get the same API into TDL data. But the project that I'm working on right now is for .NET developers. Full stop.
|
|
|
|
|
10-4.
> As to a rewrite in Java. Dead | ...
I get that java is heartily despised, and I don't doubt for good reason. (Although I do wonder how much of current feeling about it is baggage still hanging around from early days. I do expect it is rather better now, but I don't actually know that.)
I only meant to say, on that (java) ... the (supposed) 'cross-platform'ness is tantalizing, and that I believe that such a rewrite would be able to land on more platforms than you might think (given your comments). I'd also like to find a magic wand, win the lottery big time ...
Like I said, I do get you have a particular itch to scratch, for good reasons, and I certainly applaud your scratching it. (And I thank you for doing so.)
|
|
|
|
|
I have nothing against Java and might even create another library like this for Java developers. In another forum just 2 minute ago I argued that Java was indeed the best choice for a specific cross-platform project.
The intent of my comment was that you're suggesting a rewrite of TDL. I don't care what language is being discussed, that's simply not of interest to me. Dan has over a decade of development in TDL. I just want to access the TDL data, not recreate everything he's done in the UI. There is a vast difference in the scope of these things - sand castle to Egyptian Pyramid.
|
|
|
|
|
iamstarbuck wrote: Would be better to set a flag somewhere that asks TDL to release its lock, and then use another flag to tell TDL that it needs to refresh a .tdl file before continuing. TDL doesn't keep a lock per se, at most it just tags the tasklist with the user name of the person who has it checked out.
Therefore all that would probably be required would be the ability to save the current user changes and possibly notify the app that an 'external modify operation' was being carried so the user ought to be prevented from editing the tasks. The problem with this last point is that if the external app crashes or does not notify TDL that the operation has ended, then TDL will be stuck in a read-only state.
This will always be a problem with an external process modifying the tasklist directly instead of going thru the existing plugin architecture.
|
|
|
|
|
Maybe I'm missing a better way to do this. It's my understanding that TDL allows for calling TO other code but not for internal functions to be called via an Extensibility API.
Even if it does, there can easily be scenarios where TDL simply isn't running in the same server where another app is running via the library. For example, the .tdl might be in a DropBox or network drive and we have no idea how many clients access it.
I think this is exactly the kind of concurrency issue that has been discussed in the postings on Dropbox or maybe EasyFTP?
|
|
|
|
|
> My next challenge is to ensure that updates don't trash the .tdl XML
I believe this will be an insurmountable challenge. Except by accepting whatever you find with the .tdl / ignoring the .xsd, because ...
> all data is saved with proper typing
... as far as I can see ToDoList does not itself impose / strictly adhere to proper typing. (Thus the .xsd being so out of date - it isn't imported, I don't believe, with the msxsl .dll load calls, nor the save. Reacting to any msxsl save data type errors would seem to be right out.
Interestingly ... I suspect if it did pay attention to the .xsd, this would almost make the database schema user enhancable. I could in theory then add my own custom fields, and have faith that they won't be lost at each .tdl write. All in all a level of data discipline I'm not sure is currently within ToDoList, and I expect a rather non-trivial change to cause enforcement. [Granted - if I'm going to customize it and a later version of TDL trashes it, my problem, not TDL's.]
(At the least, this would almost require the requested 'rewrite .tdl per current schema' facility.)
Having said that, this would be a wonderful effort.
Even just a web facility for data entry alone would bring much to the party.
Let alone, for this to work Dan will have to seriously tighten up data type definitions and use within ToDoList.
And ... if that happens ... then moving off xsl would become possible / easier.
At which point a custom report writer would no longer be needed - there are report writers out there for other databases, and they in theory would start to 'just work.'
Presumably one of the first steps in any process along these lines is to get the source up to git / github / whatever, where multiple people can then contribute, and Dan could accept / approve patches.
It also seems to me that if you're doing this in C# (mono, please?), you'd get cross-platform compatibility (including a native linux app), and in the end be in essence doing a rewrite from VC to C#. Which may be no bad thing - but also a non-trivial amount of work.
|
|
|
|
|
I can respond to a couple of your points simply by saying once the classes are complete they don't need the xsd anymore. That's a one-shot tool to get the classes. and after the classes are available they'll serialize to the required XML, not via XSD.
As far as typing, without manual xsd tweaks, everything is a string. But my wrapper class is strongly typed for nullable Double, DateTime, Int16, Int32, Color, etc. When serializing it just goes back to strings in quotes.
Now, let's say there's an update to TDL and there's a new field. You use it in TDL. Then run a program based on the library against the .tdl file. Oops, the library isn't aware of the field so it the .tdl gets re-written without your data. The solution for that is that the library will check the Version in the library and if the library was built against a different version it will have to stop working to avoid trashing new data. I'll try to make this more elegant as time goes on, but people will have to get used to the idea that they can't use bleeding-edge releases of TDL without updating related components. There's always going to be some lag between the library and the platform, no matter what software we're talking about - look at the thousands of modules for Drupal or osCommerce or WordPress or any other FOSS where the after-market needs to catch-up to the core.
As far as web facility, this is starting as nothing more than a developer library for other developers. And yes, it's in C# and should be usable in Mono. It's not an application. It's my hope that other developers will want to build apps from this where they cannot with C++, and that this might help to build the ecosystem around TDL itself.
As to work for Dan, I dunno if he needs to change anything that he does. Although changing some things could break apps based on the library, he already knows that can happen with XML apps. As an example, I use an Enum for the TimeUnits where values are M, D, Y, etc. While Dan displays the Minutes selector as 'm', internally he uses 'i', and I have that in the Enum. I doubt he'd go and randomly change that as it would break everything in the field. So this isn't much more sensitive to changes than anything else and I don't want Dan to be encumbered by addons. As stated above this library will just need to be updated to follow along with whatever he's doing, and I trust his changes are Evolutionary, not Revolutionary.
I agree that we should be able to move toward report writers that 'just work' now that we have strongly typed classes. That will be an application which someone else might want to tackle, though I have ideas for that myself. Such applications will not be packaged with this library but will be built upon the library just like any other.
This is not a re-write of TDL in any way. I'm just making the XML data easier to read/write from outside which is what Dan wants to happen with this software. One way to look at this is that the TDL application is a provider and consumer of data. This library should allow other apps to provide and consume data from the same source. But I don't recommend an attempt to create another app that's just like TDL itself. That would be a waste of time since Dan already has that well in hand. It would be better for everyone using TDL if we had more of an ecosystem built around this with different offerings for different purposes, like reporting, imports and exports with other apps (accounting, manufacturing, ERP, QA, sales...), web services (queries and updates on the .tdls, or even integration with RDBMS. Consider how cool it might be to update your task list and have that data immediately update a RDBMS so that you an perform SQL queries, and use triggers in the database to update the .tdl file. That is one place where we can get new reporting apps from this effort.
And yes, this will get published somewhere as FOSS after it's out of an alpha state. As much as I like CodeProject the code won't be hosted here.
|
|
|
|
|
> once the classes are complete they don't need the xsd anymore.
I suspect this isn't true - it presumes a static schema. The schema will be a living, breathing, thing, and you're not going to know ahead of time when / what has changed. e.g. I believe Dan has or will finish implementing task/meta elements, and hopefully todolist/custom_meta (or whatever he calls it) elements.
> it will have to stop working to avoid trashing new data.
So, now before using a new version of TDL, users using your stuff will have to wait for you to update? What if you take a holiday?
> It's my hope that other developers will want to build apps from this where they cannot with C++, and that this might help to build the ecosystem around TDL itself.
Isn't this almost chicken and egg? Wouldn't it be easier to 'give it up' and rewrite TDL in C#, 'strongly' typed (strictly dd adherent) in the first place, and put it up in github, avoiding chicken and egg entirely, and developers can contribute to the root codebase?
All I'm thinking here is for the effort involved, both ways will be about the same amount of work I'm guessing, and this latter significantly enriches the ecosystem.
> he already knows that can happen with XML apps
And part of my point is Dan's already stated wish that he had never heard of XML in the first place. This is a path to refactor that.
> this library will just need to be updated to follow along with whatever he's doing, and I trust his changes are Evolutionary, not Revolutionary.
Without offense to Dan, he's already shown that he doesn't / isn't interested in applying things cross-app cohesively, or the xsd would always be current. Let alone the change from comment attributes to elements - you can pick the term, whether it's evolutionary or revolutionary.
> now that we have strongly typed classes
But unless I'm misunderstanding something, we don't, nor ever will. You will always be dependent upon Dan so doing. And he has demonstrated, for the purposes of his own app's evolution, he's going to create new attributes and elements willy nilly as suits his purposes. Without updating or adhering to any published xsd, and quite probably without documentation, change reports, or notification, to you.
I don't disagree with the principle of one piece of code doing one thing, really, really, well. And the idea of TDL as the non-web user interface, and other things doing reports, or web, or whatever, make a great deal of sense. However, following that idea, aside from in essence to implement 'properly' means refactoring TDL, it should also, following those principles, mean moving to a DBMS that's well proven (including maintenance utilities), and having TDL be the user interface against that. Which again means a refactoring of TDL, and probably a rewrite in a language more sustainable and cross-platform than VC. (And getting off a proprietary / $ development environment should in theory enhance the world's ability to contribute to the code base.)
I get the idea of incremental improvements. But it feels like for the same effort you could get to a much greater whole.
At least Dan's got the logic all worked out, thank goodness. Which is half the battle in writing anything in any language. (The 'business rules' as it were.)[Speaking of which ... just imagine if the database were PostgreSQL where these business rules could be written right into the schema. Then neither you, nor he, need reinvent those wheels - every element would be writing against the same back end.]
|
|
|
|
|
_BS_ wrote: > once the classes are complete they don't need the xsd anymore.
I suspect this isn't true - it presumes a static schema. The schema will be a living, breathing, thing, and you're not going to know ahead of time when / what has changed. e.g. I believe Dan has or will finish implementing task/meta elements, and hopefully todolist/custom_meta (or whatever he calls it) elements. What I mean is that the process consists of translating a .xsd file to code, and then updating the wrapper to conform to the latest version. The resulting wrapper is then compiled to a DLL which will read/write XML files which have the same schema version. There is no dynamic schema reference, the .xsd is not required at runtime.
_BS_ wrote: > it will have to stop working to avoid trashing new data.
So, now before using a new version of TDL, users using your stuff will have to wait for you to update? What if you take a holiday? The beauty of FOSS is that one doesn't need to wait for some individual to maintain code. If you know enough to update TDL then you should also know that your other FOSS that integrates with TDL is going to need related updates. You simply don't upgrade until your addons are ready. Let me be clear here: This is the way ALL addon/module/extensions software works on the internet. This is not unique. This is the way it works with Drupal, WordPress, Joomla, and just about any other FOSS package. This is the way web services work. This is the way plugins work for MS Office and your other desktop apps.
_BS_ wrote: > It's my hope that other developers will want to build apps from this where they cannot with C++, and that this might help to build the ecosystem around TDL itself.
Isn't this almost chicken and egg? Wouldn't it be easier to 'give it up' and rewrite TDL in C#, 'strongly' typed (strictly dd adherent) in the first place, and put it up in github, avoiding chicken and egg entirely, and developers can contribute to the root codebase? Feel free to re-write TDL. The code is on this page. Until that happens, Dan will continue to write in C++ and those of us who cannot contribute to his code base can make use of the built-in extensibility. (For the record I can read C++ and am checking the code as a part of my development, but I don't write C++ from scratch.)
_BS_ wrote: All I'm thinking here is for the effort involved, both ways will be about the same amount of work I'm guessing, and this latter significantly enriches the ecosystem. My effort is just to build a library to read/write data. There is no functionality implied here. When this is done, anyone can use the library to build apps. I'm not going in that direction. Your questions imply a re-write of TDL. That's WAY beyond the scope of this library project.
_BS_ wrote: > he already knows that can happen with XML apps
And part of my point is Dan's already stated wish that he had never heard of XML in the first place. This is a path to refactor that. Well, the XML and XSD are a "quick" way of getting all of the fields for the initial code generation. The current fact is that the data is in XML right now. Until that changes we're stuck with it. I just need a nice way to read XML, parse that into strongly typed classes (a tasklist and a collection of nested tasks) and then to re-serialize the data back to XML .. without breaking the .tdl file. I don't really care what the mechanism is but I'd really like to avoid manual XML document manipulation via .NET classes. Bottom line on that is that we work with what exists now. I'm not going to ask Dan to re-write the datastore. The whole point here is to get more mileage from TDL without putting the entire burden on him.
_BS_ wrote: > this library will just need to be updated to follow along with whatever he's doing, and I trust his changes are Evolutionary, not Revolutionary.
Without offense to Dan, he's already shown that he doesn't / isn't interested in applying things cross-app cohesively, or the xsd would always be current. Let alone the change from comment attributes to elements - you can pick the term, whether it's evolutionary or revolutionary. Again, I'm working with the conditions that exist.
_BS_ wrote: > now that we have strongly typed classes
But unless I'm misunderstanding something, we don't, nor ever will. You will always be dependent upon Dan so doing. And he has demonstrated, for the purposes of his own app's evolution, he's going to create new attributes and elements willy nilly as suits his purposes. Without updating or adhering to any published xsd, and quite probably without documentation, change reports, or notification, to you. Feel free to make decisions based on those assertions. As to "we don't, nor ever will", I have code here that speaks to the contrary.
In response to your other comments, I'll just reiterate: I'm working with the conditions that exist, I'm not asking Dan to do anything new, and what comes from this should be a number of new options for those who decide to make use of it.
Feel free to not use the code for all of the reasons you've cited. This might be a dismal failure in concept or implementation. If so, I'll just go back to the thousand other projects that I need to work on. I just see that Dan has busted his hump for over a decade with hardly any code contributions to support his effort, and I'm just trying to give back in a way that agrees with his patterns and preferences as much as his code.
How about this - can we shift directions a bit to talk about how this can be used instead of all the reasons why it shouldn't exist? I mean, we've tried the condition of tools like this not existing, and we've done that for a decade. Now let's try something different.
|
|
|
|
|
I hear you.
Please understand, all I have been saying is that for the amount of effort you're going to expend, and need of Dan (e.g. to ensure strict adherence to the xsd of the moment), applying that effort in a different direction is likely to provide greater returns to a greater audience. Something Dan has said he would like to see.
Ran than Dan do all the work, as you say, let's create an environment in which we can all help him in the 'rewrite'.
e.g. If you're going to do the work of data in/out, you've just completed a non-trivial portion of any rewrite - and eliminated any need to keep anything in sync, it will inherently already be in sync. If that data is in something like PostgreSQL, then strong typing is inherent to that vehicle - the code won't have to worry about making sure all i's are dotted and t's crossed, the database won't let you write non-adhering data in the first place - you may have to fix some code in a specific place for a specific field, but you'll have confidence that you won't be breaking something else. And if you do, it will be immediately noticeable when records fail to write. Data integrity will be maintained throughout, and there will be less of a need to write remediating code.
But I do get what you're saying. Today is today, and you're scratching an itch because you have a particular urge to solve a particular problem today because it's impacting you.
|
|
|
|
|
Example of application.
Skype from colleague after I introduced him to ToDoList:
"If I give you a RESTful service you can integrate it to that thing?"
Me: "yeah"
I wouldn't have been able to say that last week...
If we toss around some ideas about how we can use ToDoList data, both reading and writing our TDL data, then we can plant the seed for anyone who wants to write apps against the library later.
|
|
|
|
|
That would be great. Example code always stimulates me to consider other possibilities.
|
|
|
|
|
Sure, here are some examples:
1) Touched on in the related discussion: Reporting.
Many applications operate on a RDBMS, whether MySql, SQL Server, Oracle, or Sqlite for Android. Most reporting apps do not have a driver for XML, and those that do require a schema (which as discussed, I'll create a new schema as a by-product of this effort).
The library consists of strongly typed classes for app development but I will also add a DataTable interface for ADO.NET. With this it will be easy for someone to extract data from a .tdl, and push it into a RDBMS table for subsequent reporting - a near-line / off-line datastore. Then any reporting tool of choice can be used to operate on the data. I will not be adding exports to specific databases unless I need them. That exercise will be left to anyone who's motivated to do that kind of development.
It's good and necessary that TDL has some form of built-in reporting, so this doesn't preclude that effort. But this will offer options to those who prefer to use other reporting products, especially commercial tools that they've purchased to get consistent reporting in their department or company.
2) For CSV/Excel exports, the library can be used in conjunction with other development tools like Linq-to-CSV or Excel automation libraries. With these tools and a class library, developers will have a much easier time creating custom export utilities.
3) Developers can use this to create outbound notifications where changes to TDL trigger emails, SMS, or other notifications.
4) Developers can use this to export data from other applications into TDL. Examples include creating new tasks for sales people to notify clients of some new event, or triggers to purchasing people to check vendor pricing when it's getting close to re-order time. Someone can even wire this to a Facebook app which gets new birthday events and updates TDL with a task to go buy a gift.
5) Mobile apps can be created which monitor the installation of specific versions of software. For company use, let's say you have a Task is to get all company mobile phones upgraded to v2.0 of a specific app. You know how many phones are in the hands of company employees. That count becomes you 100% mark to task completion. As each employee gets their phone updated and notifications are sent in, the %Complete flag is updated to reflect the new count. So if there are 50 employees and 20 of them have updated, %Complete = 40. And to complete the cycle, if a read trigger is on that, when that task is 100% complete perhaps an email can be sent to management that everyone has now updated.
6) This can help to bi-directionally integrate TDL with Bugzilla or other issue tracking systems.
7) Many FOSS projects (Drupal, Wordpress, MediaWiki...) send email when there is a new release out. You can have an app monitor specific accounts for mail from these projects, and when one is found that says "you need to upgrade your software", it will create a task in your website .tdl. Or you can be pro-active and have an app poll the various websites for new releases, whether checking their FTP sites or a portal/download page. So the app queries for an update and if found it creates a new task that you should check into it.
The possibilities are endless.
|
|
|
|
|
iamstarbuck wrote: The possibilities are endless. I don't doubt that, but _I_ only get stimulated when I have example code to actually work with!
|
|
|
|
|
OK, I need to spend less time writing About the library and spend more time actually coding the library and some sample apps.
|
|
|
|
|
Hi Dan
As I understand, View > Toggle Filter will toggle between the most recent filter and the default filter (i.e. All Tasks filter). To me, this feature is very convenient. Anyway, there's a minor issue as follows:
In the All Tasks filter, the default value of "Hide Completed Tasks" is false (unchecked). So whenever I use the Toggle Filter feature to switch back to the All Tasks filter, the completed tasks show up and I have to set the “Hide Completed Tasks” option back to true (checked).
There's an option under User Interface > Column Selection which is called “Always hide parent tasks in List View”. Is it possible to add a similar option called “Always hide completed tasks in All Tasks filter”?
Thank you for the most awesome todolist application known to me (at least)
Regards
Hoa
|
|
|
|
|