[yast-devel] TimezoneSelector widget
Hi! I spent some time implementing a very rough first version of a graphical timezone selector widget and commited it into branches/tmp/coolo/zone. The widget is rather useless as it does not have any kind of valus or properties and that is what I'm wondering: what would be a good connection to ycp? I assume I need to send events if the current selection changes and I could accept a given selection from outside - e.g. from a combo box below. I guess through a property? Please help out a clueless ycp programmer :) Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Mon, Dec 17, 2007 at 10:05:29AM +0100, Stephan Kulow wrote:
I spent some time implementing a very rough first version of a graphical timezone selector widget and commited it into branches/tmp/coolo/zone.
Hey, sounds cool. Do you have a screenshot?
The widget is rather useless as it does not have any kind of valus or properties and that is what I'm wondering: what would be a good connection to ycp?
I assume I need to send events if the current selection changes and I could accept a given selection from outside - e.g. from a combo box below. I guess through a property?
I imagine a simple interface, with a single read-write property, `Value. Its type is the string that appears in /etc/sysconfig/clock:TIMEZONE (Europe/Prague in my case) The widget sends events iff it has `opt(`notify) enabled. Or we can also expose `LatLon and have Marble pop up and show my geocoded flickr pho... er, enough. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Montag 17 Dezember 2007 schrieb Martin Vidner:
On Mon, Dec 17, 2007 at 10:05:29AM +0100, Stephan Kulow wrote:
I spent some time implementing a very rough first version of a graphical timezone selector widget and commited it into branches/tmp/coolo/zone.
Hey, sounds cool. Do you have a screenshot? It's too early for screenshots, really. Think of a map of a world, that's the way the screenshot would look like :)
The only thing different is that there are little boxes on spots from /usr/share/zoneinfo/zone.tab
The widget is rather useless as it does not have any kind of valus or properties and that is what I'm wondering: what would be a good connection to ycp?
I assume I need to send events if the current selection changes and I could accept a given selection from outside - e.g. from a combo box below. I guess through a property?
I imagine a simple interface, with a single read-write property, `Value. Its type is the string that appears in /etc/sysconfig/clock:TIMEZONE (Europe/Prague in my case) The widget sends events iff it has `opt(`notify) enabled.
Europe/Prague sounds perfect Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On po 17. prosince 2007, Stephan Kulow wrote:
Hi!
I spent some time implementing a very rough first version of a graphical timezone selector widget and commited it into branches/tmp/coolo/zone.
The widget is rather useless as it does not have any kind of valus or properties and that is what I'm wondering: what would be a good connection to ycp?
I assume I need to send events if the current selection changes and I could accept a given selection from outside - e.g. from a combo box below. I guess through a property?
Please help out a clueless ycp programmer :)
For a current time zone data used by YaST, see the file timezone_raw.ycp (under /usr/share/YaST2/data or country/timezone/data in svn). It's a map of regions, each with a submap of the time zone names. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Monday 17 December 2007 10:27:39 Jiří Suchomel wrote:
For a current time zone data used by YaST, see the file timezone_raw.ycp (under /usr/share/YaST2/data or country/timezone/data in svn). It's a map of regions, each with a submap of the time zone names.
Why is this data in ycp format instead on some data format that can be read from ycp?. I remember someone using our timezone data from non-YaST, they had to implement a pseudo YCP parser to be able to read it :-( Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Duncan Mac-Vicar Prett wrote:
On Monday 17 December 2007 10:27:39 Jiří Suchomel wrote:
For a current time zone data used by YaST, see the file timezone_raw.ycp (under /usr/share/YaST2/data or country/timezone/data in svn). It's a map of regions, each with a submap of the time zone names.
Why is this data in ycp format instead on some data format that can be read from ycp?.
To be simply-maintainable and to simply generate translations I guess. I don't remember anyone using the data anywhere else. So as the data were used only from YaST (I hadn't known they weren't) it was/is the easies way. YaST developers usually don't implement something in the hardest way they could imagine just to show how great hackers they are :) ;) Lukas
On po 17. prosince 2007, Duncan Mac-Vicar Prett wrote:
On Monday 17 December 2007 10:27:39 Jiří Suchomel wrote:
For a current time zone data used by YaST, see the file timezone_raw.ycp (under /usr/share/YaST2/data or country/timezone/data in svn). It's a map of regions, each with a submap of the time zone names.
Why is this data in ycp format instead on some data format that can be read from ycp?.
Because ycp format can be read from ycp in the easiest way? Or because nobody requested anything different?
I remember someone using our timezone data from non-YaST, they had to implement a pseudo YCP parser to be able to read it :-(
This is first time I hear about such attempt.
Duncan
jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Montag 17 Dezember 2007 schrieb Duncan Mac-Vicar Prett:
On Monday 17 December 2007 10:27:39 Jiří Suchomel wrote:
For a current time zone data used by YaST, see the file timezone_raw.ycp (under /usr/share/YaST2/data or country/timezone/data in svn). It's a map of regions, each with a submap of the time zone names.
Why is this data in ycp format instead on some data format that can be read from ycp?.
I remember someone using our timezone data from non-YaST, they had to implement a pseudo YCP parser to be able to read it :-(
Or asked differently: is it possible to pass this map as argument to a mod-ui widget? I couldn't find any taking a list or a map. If that's possible, I would change the widget to have a list of timezones wanted. So I would only display what's in that map _and_ in zone.tab - but a map with any won't work, a map<string,string> would. Another problem not mentioned in the original mail: where to store the jpg and how to find it? I don't think it should be in yast2-qt as other UIs should share the jpg and it's really only interesting for yast2-country. So I put a "map" filename argument to the widget, that the ycp code has to give. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On po 17. prosince 2007, Stephan Kulow wrote:
Am Montag 17 Dezember 2007 schrieb Duncan Mac-Vicar Prett:
On Monday 17 December 2007 10:27:39 Jiří Suchomel wrote:
For a current time zone data used by YaST, see the file timezone_raw.ycp (under /usr/share/YaST2/data or country/timezone/data in svn). It's a map of regions, each with a submap of the time zone names.
Why is this data in ycp format instead on some data format that can be read from ycp?.
I remember someone using our timezone data from non-YaST, they had to implement a pseudo YCP parser to be able to read it :-(
Or asked differently: is it possible to pass this map as argument to a mod-ui widget? I couldn't find any taking a list or a map.
If that's possible, I would change the widget to have a list of timezones wanted. So I would only display what's in that map _and_ in zone.tab - but a map with any won't work, a map<string,string> would.
The current format of timezone_raw.ycp is probably not best for your purposes, for example you probably won't need those regions at all (they were defined by us just to ease the navigation, it's no standard). So I think for your purpose I could pass a map<string,string>: time zone name -> translated name, just like "Europe/Prague" : _("Czech Republic"). But I would not like to throw away the current map at all, because I assume ncurses timezone selection won't be affected and current format with regions fits well there. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Montag 17 Dezember 2007 schrieb Jiří Suchomel:
But I would not like to throw away the current map at all, because I assume ncurses timezone selection won't be affected and current format with regions fits well there.
Sure, I don't have a problem in filtering out something I don't need. I just have to have a way not to duplicate the information. So perhaps you can come up with a compromise data structure that can be passed to C++ without giving up the regions? E.g. Europe#Europe/Prague : _("Czech Republic") - assuming you can split strings in ycp :) But if it's easier to create a second map from that original map, it's of course fine with me as well. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On po 17. prosince 2007, Stephan Kulow wrote:
Am Montag 17 Dezember 2007 schrieb Jiří Suchomel:
But I would not like to throw away the current map at all, because I assume ncurses timezone selection won't be affected and current format with regions fits well there.
Sure, I don't have a problem in filtering out something I don't need. I just have to have a way not to duplicate the information. So perhaps you can come up with a compromise data structure that can be passed to C++ without giving up the regions? E.g. Europe#Europe/Prague : _("Czech Republic") - assuming you can split strings in ycp :)
But if it's easier to create a second map from that original map, it's of course fine with me as well.
From YCP, it is easy to simplify the map to create a one in requested format, so I'd prefer going this way. Just define the desired input format and I'll prepare it for you :-)
Greetings, Stephan
Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Montag 17 Dezember 2007 schrieb Jiří Suchomel:
On po 17. prosince 2007, Stephan Kulow wrote:
Am Montag 17 Dezember 2007 schrieb Jiří Suchomel:
But I would not like to throw away the current map at all, because I assume ncurses timezone selection won't be affected and current format with regions fits well there.
Sure, I don't have a problem in filtering out something I don't need. I just have to have a way not to duplicate the information. So perhaps you can come up with a compromise data structure that can be passed to C++ without giving up the regions? E.g. Europe#Europe/Prague : _("Czech Republic") - assuming you can split strings in ycp :)
But if it's easier to create a second map from that original map, it's of course fine with me as well.
From YCP, it is easy to simplify the map to create a one in requested format, so I'd prefer going this way. Just define the desired input format and I'll prepare it for you :-)
That still leaves me without knowing how to put that map into C++ Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Dňa Monday 17 December 2007 11:26:14 Stephan Kulow ste napísal:
Am Montag 17 Dezember 2007 schrieb Jiří Suchomel:
On po 17. prosince 2007, Stephan Kulow wrote:
Am Montag 17 Dezember 2007 schrieb Jiří Suchomel:
But I would not like to throw away the current map at all, because I assume ncurses timezone selection won't be affected and current format with regions fits well there.
Sure, I don't have a problem in filtering out something I don't need. I just have to have a way not to duplicate the information. So perhaps you can come up with a compromise data structure that can be passed to C++ without giving up the regions? E.g. Europe#Europe/Prague : _("Czech Republic") - assuming you can split strings in ycp :)
But if it's easier to create a second map from that original map, it's of course fine with me as well.
From YCP, it is easy to simplify the map to create a one in requested format, so I'd prefer going this way. Just define the desired input format and I'll prepare it for you :-)
That still leaves me without knowing how to put that map into C++
The map will be passed as a std::map or YCPMap (wrapper around std:map) to you via all kinds of calls in yast2-core. What's the API to YCP? UI::ChangeWidget() ? Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Mon, Dec 17, 2007 at 10:27:39AM +0100, Jiří Suchomel wrote:
For a current time zone data used by YaST, see the file timezone_raw.ycp
http://svn.suse.de/svn/yast/trunk/country/timezone/data/timezone_raw.ycp -- http://en.opensuse.org/User:Mvidner - http://en.opensuse.org/YaST http://en.wikipedia.org/wiki/Software_developer http://en.wikipedia.org/wiki/Wink -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 17/12/2007, Stephan Kulow <coolo@kde.org> wrote:
Hi!
I spent some time implementing a very rough first version of a graphical timezone selector widget and commited it into branches/tmp/coolo/zone.
Nice. Slightly off-topic but could you check that it's easy to select cities in Europe with it? The Kubuntu implementation of this makes it difficult to select where you live if you don't live in the US. It requires a lot of dexterity with the mouse to select a specific city in more densely populated areas. The ubuntu version is better though as it has more seamless zooming. Also what about using a geo-ip service to find out where a user is likely to be if connected to the internet and pre-zooming the map? download.opensuse.org already knows this. I guess this might mean exposing zoom level / area through YCP interface somehow. -- Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Montag 17 Dezember 2007 schrieb Benji Weber:
On 17/12/2007, Stephan Kulow <coolo@kde.org> wrote:
Hi!
I spent some time implementing a very rough first version of a graphical timezone selector widget and commited it into branches/tmp/coolo/zone.
Nice.
Slightly off-topic but could you check that it's easy to select cities in Europe with it? The Kubuntu implementation of this makes it difficult to select where you live if you don't live in the US. It requires a lot of dexterity with the mouse to select a specific city in more densely populated areas. The ubuntu version is better though as it has more seamless zooming.
The ubuntu version is "stolen" from ximian and not reimplemented for kubuntu - for whatever reason. And I took ubuntu's idea, even though I could not use much of the code. For my experiments I used http://radcyberzine.com/xglobe/caida_1280.jpg (which is copyright free) and for someone like me it's hard to know to differ Prague and Berlin on first view - fortunately enough it does not matter as long as they have the same timezone :)
Also what about using a geo-ip service to find out where a user is likely to be if connected to the internet and pre-zooming the map? download.opensuse.org already knows this. I guess this might mean exposing zoom level / area through YCP interface somehow.
I don't want to have internet during installation and I don't want to spend much time on implementing something I won't use for installation. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Monday 17 December 2007 10:05, Stephan Kulow wrote:
The widget is rather useless as it does not have any kind of valus or properties and that is what I'm wondering: what would be a good connection to ycp?
I assume I need to send events if the current selection changes and I could accept a given selection from outside - e.g. from a combo box below. I guess through a property?
The semantics or such a widget are similar to a selection widget (like combo box or selection box), so it should have a "Value" property that can be queried and set, and it should send a YSelectionChangedEvent if (and only if) "notify" (`opt(`notify)) is set. If you subclass it from YSelectionWidget (which I strongly recommend), you can reuse a lot of infrastructure. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Montag 17 Dezember 2007 schrieb Stefan Hundhammer:
On Monday 17 December 2007 10:05, Stephan Kulow wrote:
The widget is rather useless as it does not have any kind of valus or properties and that is what I'm wondering: what would be a good connection to ycp?
I assume I need to send events if the current selection changes and I could accept a given selection from outside - e.g. from a combo box below. I guess through a property?
The semantics or such a widget are similar to a selection widget (like combo box or selection box), so it should have a "Value" property that can be queried and set, and it should send a YSelectionChangedEvent if (and only if) "notify" (`opt(`notify)) is set.
If you subclass it from YSelectionWidget (which I strongly recommend), you can reuse a lot of infrastructure.
I looked at it and couldn't find a single method that's useful for me. Unless I want every timezone to be an item, which I consider overkill. So I implemented the changedEvent, which was just one line. But what I wonder the most: are my changes to core ok now for trunk? I'd work on the actual implementation with zooming and drawing, but the interface to ycp should be "ok" now. So please review: svn diff -r43109:HEAD http://svn.opensuse.org/svn/yast/branches/tmp/coolo/zone/core (also my ycp code in the example :) Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 18 December 2007 12:28, Stephan Kulow wrote:
But what I wonder the most: are my changes to core ok now for trunk? I'd work on the actual implementation with zooming and drawing, but the interface to ycp should be "ok" now.
So please review: svn diff -r43109:HEAD http://svn.opensuse.org/svn/yast/branches/tmp/coolo/zone/core
Looks good to me. But it might be a good idea to add a private: ImplPtr<YTimezoneSelectorPrivate> priv; member to class YTimezoneSelector, even if it just contains a bool dummy. If ever this class should require any real data, binary compatibility will not be broken right away if that pointer is there from the very beginning. It costs us one pointer (4 bytes) and a bool ( 1 byte + padding for the struct), i.e. ~8 bytes per YTimezoneSelector widget; very few bytes to prevent future binary compatibility breakages. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Dienstag 18 Dezember 2007 schrieb Stefan Hundhammer:
On Tuesday 18 December 2007 12:28, Stephan Kulow wrote:
But what I wonder the most: are my changes to core ok now for trunk? I'd work on the actual implementation with zooming and drawing, but the interface to ycp should be "ok" now.
So please review: svn diff -r43109:HEAD http://svn.opensuse.org/svn/yast/branches/tmp/coolo/zone/core
Looks good to me.
But it might be a good idea to add a
private: ImplPtr<YTimezoneSelectorPrivate> priv;
member to class YTimezoneSelector, even if it just contains a bool dummy. If ever this class should require any real data, binary compatibility will not be broken right away if that pointer is there from the very beginning.
Good point. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (8)
-
Benji Weber -
Duncan Mac-Vicar Prett -
Jiří Suchomel -
Lukas Ocilka -
Martin Vidner -
Stanislav Visnovsky -
Stefan Hundhammer -
Stephan Kulow