GNOME Bugzilla – Bug 52372
Suggested GnomeDateEdit Enhancements for 2.2
Last modified: 2013-02-03 22:06:59 UTC
First and foremost, you should be able to display just the time portion of the widget. The date_changed/time_changed signals should get triggered when the user types into either entry widget, not just when the calendar widget is popped down. Dates should either be internationalized or at least switched to the Japanese style (YYYY/MM/DD) for the least ambiguity. It is possible and desirable to have the time and date entries initially be blank, but subsequently clicking the calendar button will warp to 1900 instead of to today's date as it should. An alternative implementation would be to allow the user to only enter valid dates without taking away the ability to manually enter a date. It is possibly to achieve all of these (except internationalization) through crude internal hacks, but they should be portable parts of the API.
Assigning this bug to myself.
Adding keywords on bugs I've touched. This is basically spam; you can filter on the phrase 'luis doing GNOME2 work' to get rid of them all.
Unfortunately we can't add any API at this point. Sorry for not looking at it sooner :(
Actually I would suggest, redesigning the API for GnomeDateEdit from scratch. The current design, using flags to set certain attributes is just ugly; GnomeDateEdit should have appropriate accessor methods. Also, you should be able to enter dates that are outside the - quite limited - Unix epoch - this makes the widget quite unflexible and not really suited for stuff like birthdates etc. Another suggestion concerns the AM/PM and week start flags: It would be great if this doesn't had to be set on a per-application basis, but if there would be a gnome-wide gconf flag that GnomeDateEdit honours. Yes, I am willing to think about a new design and also to implement it if something like this is accepted. (I'm currently porting and redesigning gnome-pim, so it's hardly extra work.)
It would make GnomeDateEdit many times more useful if it could accept dates outside of the Unix epoch. At the moment, entering a date (manually) outside the epoch (eg 1800) is accepted, but internally recognised as 2000 and the selector jumps to this next time you try to use it. This is a bit like y2k-incompliance, but this time it's epoch-incompliance :)
The time selector would be better as a single GtkSpinButton. The current view does not match the model because it displays two times, only one of which is valid. The option menu does not display the actual data except by coincidence. An option menu should not have submenus. Should I report this comment as a separate bug?
Created attachment 10620 [details] Suggestion for a new API as sent to gtk-devel-list and gnome-hackers
Sebastian: This fixes my problems with GnomeDateTime. Where is the discussion on the lists? (My searches returned 0 results). Are you making sure that the date and time are displayed consistantly with the user's locale settings as well? For example, here in England, a date should be DD/MM/(YY)YY. PS. Thanks!
> Where is the discussion on the lists? (My searches returned 0 results). The post is probably still awaiting moderator approval. Should appear soon. (I hope.) > Are you making sure that the date and time are displayed consistantly with the user's locale settings as well? For example, here in England, a date should be DD/MM/(YY)YY. Definately. Basically I plan to use the existing GnomeDateEdit and build on top of that.
If there are patches to make the 1.4.x version better I'd love to include those. Assuming they don't break ABI/API compat of course.
Just for the record: http://me.in-berlin.de/~jroger/gnome/libegg-datetime-2.patch contains a suggested implementation for the new API (with a few changes). This patch is relative to libegg, but slightly outdated as of now. It's mostly complete.
If the calendar is going to be kept private, I would like to have a signal for when the calender is hidden, which probably means the user has finished entering the date. So in addition to 'date_changed', how about 'date_finalized'. Or maybe 'date_changed' should only be emitted when the date has been finalized, since it doesn't seem that most apps would care about incremental date changes and would only want the final selected date.
The patches on my page are now considered out-dated by me. The current version (with bug fixes) can now be found in GNOME CVS, directory gnome-pim/libegg, since I'm now using this widget for the GNOME 2 version of GNOME-PIM. I would really love to get this into libegg proper, though ...
Jacob: This is a good suggestion, and I'm implementing it now.
Now is the time to get this into libegg or libgnomeui for inclusion in 2.4.
I would love to commit my EggDateTime widget to the libegg module to make it available for digestion and hacking to a wider audience, but I still need the permission of a module owner to do so. I will mail Owen again to have a look at this bug.
I'd recommend trying to get this into Gtk+, since there's no reason why it should be limited to libgnomeui-using apps only.
Any news here?
Moving to gtk+ for comments there.
*** Bug 111513 has been marked as a duplicate of this bug. ***
For the record: Since Owen signalled interest in a date/time widget in Gtk (post 2.4), I just committed EggDateTime to libegg. Further discussion on the API should probably take place on gtk-devel-list. I will send an initial announcement there.
In relation to comments made regarding the date_changed/time_changed signals not getting triggered when the user types into either entry widget, I believe this is a particular example of my more general bug: http://bugzilla.gnome.org/show_bug.cgi?id=156017 In relation to the other issue this bug discusses ... not being able to enter dates outside the Unix epoch, I have just hit this problem and was about to enter a bug report for it. I am building database apps and need the DateEdit widget to be able to handle NULL ( or undef, whatever ) values. There are cases where a field in a database simply doesn't have a date in it ... which is quite a valid situation. Currently I am unable to use Gnome's DateEdit widget because of this, and instead use a Gtk2Calendar ... which *kinda* provides support for NULL values by letting you set the day to zero. When I retrieve the date, I can then intrepret a date with a day equal to zero as being a NULL value, even though the month and year are still set. Could we please have this functionality in the DateEdit widget?
I don't know about Gtk+ 2.0, but our Glade 1.x application checks to see whether the two GtkEntry widgets are blank. If they are blank, then the date is NULL or not applicable. I'm not sure if this is even possible with Gtk+/GNOME/Glade 2.x. Maybe we'll port our application when this bug is fixed. Our application uses 128 GtkCLists, which I hear has been dropped, so I'm not looking forward to this.
*** Bug 172729 has been marked as a duplicate of this bug. ***
closing old bugs