After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 52372 - Suggested GnomeDateEdit Enhancements for 2.2
Suggested GnomeDateEdit Enhancements for 2.2
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other All
: Normal enhancement
: Medium API
Assigned To: gtk-bugs
gtk-bugs
: 111513 172729 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-03-21 17:08 UTC by jgotts
Modified: 2013-02-03 22:06 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Suggestion for a new API as sent to gtk-devel-list and gnome-hackers (6.83 KB, text/plain)
2002-08-21 15:53 UTC, Sebastian Rittau
Details

Description jgotts 2001-03-21 17:08:37 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.
Comment 1 Anders Carlsson 2001-09-01 19:40:40 UTC
Assigning this bug to myself.
Comment 2 Luis Villa 2002-01-24 19:07:40 UTC
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.
Comment 3 Anders Carlsson 2002-02-11 02:09:12 UTC
Unfortunately we can't add any API at this point. Sorry for not
looking at it sooner :(
Comment 4 Sebastian Rittau 2002-04-01 11:30:38 UTC
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.)
Comment 5 Andrew Sobala 2002-06-15 10:12:04 UTC
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 :)
Comment 6 Gregory Merchan 2002-08-17 04:08:48 UTC
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?
Comment 7 Sebastian Rittau 2002-08-21 15:53:44 UTC
Created attachment 10620 [details]
Suggestion for a new API as sent to gtk-devel-list and gnome-hackers
Comment 8 Andrew Sobala 2002-08-21 17:38:57 UTC
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!
Comment 9 Sebastian Rittau 2002-08-21 17:43:34 UTC
> 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.
Comment 10 Kjartan Maraas 2002-08-21 20:47:29 UTC
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.
Comment 11 Sebastian Rittau 2002-12-16 11:24:38 UTC
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.
Comment 12 Jacob Perkins 2003-02-08 02:15:40 UTC
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.
Comment 13 Sebastian Rittau 2003-02-08 11:28:41 UTC
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 ...
Comment 14 Sebastian Rittau 2003-02-08 11:31:18 UTC
Jacob: This is a good suggestion, and I'm implementing it now.
Comment 15 Kjartan Maraas 2003-05-12 20:31:17 UTC
Now is the time to get this into libegg or libgnomeui for inclusion in
2.4.
Comment 16 Sebastian Rittau 2003-05-13 03:15:18 UTC
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.
Comment 17 Andrew Sobala 2003-05-13 15:16:36 UTC
I'd recommend trying to get this into Gtk+, since there's no reason
why it should be limited to libgnomeui-using apps only.
Comment 18 Kjartan Maraas 2003-05-18 19:20:44 UTC
Any news here?
Comment 19 Kjartan Maraas 2003-05-18 19:23:06 UTC
Moving to gtk+ for comments there.
Comment 20 Owen Taylor 2003-05-20 16:24:18 UTC
*** Bug 111513 has been marked as a duplicate of this bug. ***
Comment 21 Sebastian Rittau 2003-05-25 00:37:11 UTC
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.
Comment 22 Daniel Kasak 2005-01-14 01:28:07 UTC
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?
Comment 23 jgotts 2005-01-14 05:48:07 UTC
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.
Comment 24 Matthias Clasen 2005-04-05 22:07:17 UTC
*** Bug 172729 has been marked as a duplicate of this bug. ***
Comment 25 Matthias Clasen 2013-02-03 22:06:59 UTC
closing old bugs