From: <dri...@ne...> - 2006-04-05 21:16:48
|
Saving on exit sucked, but so does the fact that gaim does a slow save to my USB key every time I change window placement. In fact I think it's only the window placements that I wouldn't save - they seem like pretty transient details compared to the other prefs anyway. cheers chris Etan Reisner <de...@ed...> wrote: >On Tue, 4 Apr 2006, Richard Laager wrote: >Purely for the record (and assuming I remember correctly), gaim used to >only save on exit, the current method is leaps and bounds better than >that one was. > >To respond to later comments, we can't decide to only save on certain >preference changes, that's asking for annoyance and stupidity. Either we >keep a list ourselves (which means plugin preferences never count) or we >let people specify (which means that all plugin preferences are likely >to count as everyone thinks they are important). > -Etan __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp |
From: <dri...@ne...> - 2006-04-15 17:11:11
|
You *could* write to the temp directory and only dump to the USB key on exit, but writing to anything other than temp kind of defeats the object of using a USB key. Personally I wouldn't write anything especially for USB keys at - just put an "only save on exit" option on the plugin. cheers chris "Mike Sartain" <mik...@gm...> wrote: >On 4/10/06, Etan Reisner <de...@ed...> wrote: >> >> On Thu, 6 Apr 2006, Mike Sartain wrote: >> >> Just out of curiosity, what changes do you think gaim would need? >> >Another possible feature which would eliminate the amount of preference >writing would be to guarantee that the extension is unloaded after all other >windows are destroyed. Then we could have a Window create / destroy hook and >only update the data at those times vs every window move. I personally don't >think this is a great idea even if doable because it also means a crash >would lose any changes users made since startup. > >The other question I was wondering about is how this should behave on a usb >key. Is a simple check making sure the window isn't off the screen(s) on the >new computer and scooting it into place on startup ok? Or would it be nice >to have an option to store this data locally on the machine and not in the >Gaim prefs file? > -Mike > __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp |
From: Evan S. <ev...@dr...> - 2006-04-05 23:58:27
Attachments:
PGP.sig
|
On Apr 5, 2006, at 5:16 PM, dri...@ne... wrote: > Saving on exit sucked, but so does the fact that gaim does a slow > save to my USB key every time I change window placement. In fact I > think it's only the window placements that I wouldn't save - they > seem like pretty transient details compared to the other prefs anyway. > What about saving them but not requesting the write? That is, the preference is retained but is only saved to disk (1) when some other preference changes or (2) on quit, whichever happens first. -Evan > cheers > chris > > Etan Reisner <de...@ed...> wrote: > >> On Tue, 4 Apr 2006, Richard Laager wrote: >> Purely for the record (and assuming I remember correctly), gaim >> used to >> only save on exit, the current method is leaps and bounds better than >> that one was. >> >> To respond to later comments, we can't decide to only save on certain >> preference changes, that's asking for annoyance and stupidity. >> Either we >> keep a list ourselves (which means plugin preferences never count) >> or we >> let people specify (which means that all plugin preferences are >> likely >> to count as everyone thinks they are important). >> -Etan > > __________________________________________________________________ > Switch to Netscape Internet Service. > As low as $9.95 a month -- Sign up today at http://isp.netscape.com/ > register > > Netscape. Just the Net You Need. > > New! Netscape Toolbar for Internet Explorer > Search from anywhere on the Web and block those annoying pop-ups. > Download now at http://channels.netscape.com/ns/search/install.jsp > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > |
From: Richard L. <rl...@wi...> - 2006-04-06 01:47:08
|
On Wed, 2006-04-05 at 19:58 -0400, Evan Schoenberg wrote: > On Apr 5, 2006, at 5:16 PM, dri...@ne... wrote: > > > Saving on exit sucked, but so does the fact that gaim does a slow > > save to my USB key every time I change window placement. In fact I > > think it's only the window placements that I wouldn't save - they > > seem like pretty transient details compared to the other prefs anyway. > > > What about saving them but not requesting the write? That is, the > preference is retained but is only saved to disk (1) when some other > preference changes or (2) on quit, whichever happens first. This means we have to determine what is an important or unimportant change. I don't think it's worth the code complexity to bother with. And, as Etan mentioned, it gets really messy when you try to factor in plugin prefs. I don't think that we should be saving the window positions on Linux, as that's a window manager issue. That would avoid this entire problem, as that seems to be the only pref that people complain about. I don't have a solution for this problem on Windows, but that wouldn't impact me anyway. Richard |
From: Etan R. <de...@ed...> - 2006-04-06 02:08:40
|
On Wed, 5 Apr 2006, Richard Laager wrote: > On Wed, 2006-04-05 at 19:58 -0400, Evan Schoenberg wrote: >> On Apr 5, 2006, at 5:16 PM, dri...@ne... wrote: >> >>> Saving on exit sucked, but so does the fact that gaim does a slow >>> save to my USB key every time I change window placement. In fact I >>> think it's only the window placements that I wouldn't save - they >>> seem like pretty transient details compared to the other prefs anyway. >>> >> What about saving them but not requesting the write? That is, the >> preference is retained but is only saved to disk (1) when some other >> preference changes or (2) on quit, whichever happens first. > > This means we have to determine what is an important or unimportant > change. I don't think it's worth the code complexity to bother with. > And, as Etan mentioned, it gets really messy when you try to factor in > plugin prefs. > > I don't think that we should be saving the window positions on Linux, as > that's a window manager issue. That would avoid this entire problem, as > that seems to be the only pref that people complain about. I don't have > a solution for this problem on Windows, but that wouldn't impact me > anyway. > > Richard I'd say pull the window position preferences entirely (including for the buddy list, but I suspect that one will cause much yelling). There is already a plugin for Windows that remembers the placement of the conversation windows (and other windows as I understand it), it should handle any windows it needs to. I'd be all for making it easier for that plugin to do the job right (patches welcome). -Etan |
From: Ethan B. <ebl...@cs...> - 2006-04-06 03:28:30
|
Etan Reisner spake unto us the following wisdom: > I'd say pull the window position preferences entirely (including for the= =20 > buddy list, but I suspect that one will cause much yelling). There is=20 > already a plugin for Windows that remembers the placement of the=20 > conversation windows (and other windows as I understand it), it should=20 > handle any windows it needs to. I'd be all for making it easier for that= =20 > plugin to do the job right (patches welcome). I agree with this wholeheartedly. The only thing Gaim can possibly do is get it wrong, anyway -- this is the window manager's job. The most gaim should do is support -geometry and offer to regurgitate it to a session manager which asks for it. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Mike S. <mik...@gm...> - 2006-04-06 03:46:56
|
On 4/5/06, Etan Reisner <de...@ed...> wrote: > I'd say pull the window position preferences entirely (including for the > buddy list, but I suspect that one will cause much yelling). There is > already a plugin for Windows that remembers the placement of the > conversation windows (and other windows as I understand it), it should > handle any windows it needs to. I'd be all for making it easier for that > plugin to do the job right (patches welcome). The Windows plugin uses a win32 cbt and shell hook to get a callback whenever a new toplevel window is created or moved. And it currently isn't filtering out anything Gaim is positioning (which is just the buddy-list right now I believe). It also doesn't store width/height for any of the windows (except for forcing specific conversations sizes) since you currently handle all that - but it would be trivial to add. And obviously if there is anything specific you folks would like added/removed/changed, I'd be more than happy to help in whatever way I could. -Mike |
From: Kevin M S. <ke...@si...> - 2006-04-06 03:41:53
Attachments:
signature.asc
|
Ethan Blanton wrote: > Etan Reisner spake unto us the following wisdom: >> I'd say pull the window position preferences entirely (including for t= he=20 >> buddy list, but I suspect that one will cause much yelling). There is = >> already a plugin for Windows that remembers the placement of the=20 >> conversation windows (and other windows as I understand it), it should= =20 >> handle any windows it needs to. I'd be all for making it easier for th= at=20 >> plugin to do the job right (patches welcome). >=20 > I agree with this wholeheartedly. The only thing Gaim can possibly do > is get it wrong, anyway -- this is the window manager's job. The most > gaim should do is support -geometry and offer to regurgitate it to a > session manager which asks for it. >=20 In that case, I'd advocate including a plugin in Gaim's distribution that can remember window positions as Windows cannot do this itself, thus effectively requiring Windows users to find an external plugin or have Gaim's windows always opening in the top left corner (or cascading with other windows) depending on which GTK version is being used. Most people would probably dislike having the buddy list appear in an inconsistent or consistently bad place every time Gaim is started. Kevin |
From: Richard L. <rl...@wi...> - 2006-04-06 06:56:17
|
On Wed, 2006-04-05 at 22:41 -0500, Kevin M Stange wrote: > In that case, I'd advocate including a plugin in Gaim's distribution > that can remember window positions as Windows cannot do this itself, I agree. We could also look into activating this plugin (and the systray plugin, as per that SF Feature Request from a few weeks ago) by default on Windows. Richard |
From: Etan R. <de...@ed...> - 2006-04-06 03:48:19
|
On Wed, 5 Apr 2006, Kevin M Stange wrote: > Ethan Blanton wrote: >> Etan Reisner spake unto us the following wisdom: >>> I'd say pull the window position preferences entirely (including for the >>> buddy list, but I suspect that one will cause much yelling). There is >>> already a plugin for Windows that remembers the placement of the >>> conversation windows (and other windows as I understand it), it should >>> handle any windows it needs to. I'd be all for making it easier for that >>> plugin to do the job right (patches welcome). >> >> I agree with this wholeheartedly. The only thing Gaim can possibly do >> is get it wrong, anyway -- this is the window manager's job. The most >> gaim should do is support -geometry and offer to regurgitate it to a >> session manager which asks for it. >> > > In that case, I'd advocate including a plugin in Gaim's distribution > that can remember window positions as Windows cannot do this itself, > thus effectively requiring Windows users to find an external plugin or > have Gaim's windows always opening in the top left corner (or cascading > with other windows) depending on which GTK version is being used. Most > people would probably dislike having the buddy list appear in an > inconsistent or consistently bad place every time Gaim is started. > > Kevin I have only small problems with doing this, assuming the plugin was written well and did things cleanly. (This likely would require some changes to gaim to make doing this easier.) -Etan |
From: Eduardo <ep...@us...> - 2006-04-06 10:20:17
|
On 2006-04-05 21:16:17 UTC, dri...@ne... wrote: > Saving on exit sucked, but so does the fact that gaim does a slow save to my USB key every time I change window placement. In fact I think it's only the window placements that I wouldn't save - they seem like pretty transient details compared to the other prefs anyway. I think the solution here is to make gaim_util_write_data_to_file() play nicely with the glib main loop, because I think currently the calls in there are blocking the GUI thus making users with slow storage go nuts. If we can make gaim_util_write_data_to_file() asynchronous we will be able to even cancel call requests when there is a new call to gaim_util_write_data_to_file() with newer data and the older call has not even finished, thus making less calls when changing many preferences in a row (even possibly getting rid of the save timer) and making the GUI not block in any situation. (Saving on exit sucked and that is not a solution) > Etan Reisner <de...@ed...> wrote: > >On Tue, 4 Apr 2006, Richard Laager wrote: > >Purely for the record (and assuming I remember correctly), gaim used to > >only save on exit, the current method is leaps and bounds better than > >that one was. > > > >To respond to later comments, we can't decide to only save on certain > >preference changes, that's asking for annoyance and stupidity. Either we > >keep a list ourselves (which means plugin preferences never count) or we > >let people specify (which means that all plugin preferences are likely > >to count as everyone thinks they are important). |
From: Ethan B. <ebl...@cs...> - 2006-04-06 18:44:30
|
Eduardo P=E9rez spake unto us the following wisdom: > I think the solution here is to make gaim_util_write_data_to_file() play > nicely with the glib main loop, because I think currently the calls in > there are blocking the GUI thus making users with slow storage go nuts. fsync() is synchronous by default, this is a non-starter. If you mean with respect to the "writing to my USB key is slow" comment, I'm sure that user is using Windows, which has a completely worthless VFS. In any real operating system, it won't matter if you're writing to a USB key or a hard disk or a freaking magnetic tape -- the VFS will make your writes ~instantaneous. Our configs just aren't that big. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Mike S. <mik...@gm...> - 2006-04-06 12:42:27
|
On 4/5/06, Etan Reisner <de...@ed...> wrote: > I have only small problems with doing this, assuming the plugin was > written well and did things cleanly. (This likely would require some > changes to gaim to make doing this easier.) Just out of curiosity, what changes do you think gaim would need? -Mike |
From: Etan R. <de...@ed...> - 2006-04-11 04:05:27
|
On Thu, 6 Apr 2006, Mike Sartain wrote: > On 4/5/06, Etan Reisner <de...@ed...> wrote: > >> I have only small problems with doing this, assuming the plugin was >> written well and did things cleanly. (This likely would require some >> changes to gaim to make doing this easier.) > > Just out of curiosity, what changes do you think gaim would need? > -Mike You tell me? Can you currently keep track of every window that you would need/want to? Can you do it easily and cleanly? Can you get notified of new windows early enough to move them usefully? If the answer to any of those is 'no' or 'not really' or even 'yes, but it could be nicer' than that is what I was referring to. If, on the other hand, the answer to all of those is 'yeah, everything works perfectly' than that's great. -Etan |
From: Mike S. <mik...@gm...> - 2006-04-11 04:56:12
|
On 4/10/06, Etan Reisner <de...@ed...> wrote: > > On Thu, 6 Apr 2006, Mike Sartain wrote: > > Just out of curiosity, what changes do you think gaim would need? > > You tell me? Can you currently keep track of every window that you would > need/want to? Can you do it easily and cleanly? Can you get notified of > new windows early enough to move them usefully? I just wasn't sure if you'd looked over the problem already and had something specific in mind. But if you're asking me, I'd say it depends on the feature set you want. First off, I'm assuming this will be a Windows only extension since, from what I can tell, other platforms handle this already. If that's true and you want the very basic solution which uses jus= t the window titles to store the window position & dimensions, then everythin= g is set - the current Window hook apis appear to work quite well in a fairly small amount of code. If you want to use the gtk window role & title as the key (a class/title type thing which I'm currently doing to avoid potential conflicts) or you want any of those extra current extpos features (which should probably stay as a 3rd party plugin feature), then yes, it might be nice if we didn't hav= e to enumerate all the top level gtk windows comparing native handles to find the GtkWindow information. If you'd like to extend the current extension api to not require Window api= s or to run this on other platforms, then callbacks for whenever GtkWindows are created and/or moved would be necessary. Another possible feature which would eliminate the amount of preference writing would be to guarantee that the extension is unloaded after all othe= r windows are destroyed. Then we could have a Window create / destroy hook an= d only update the data at those times vs every window move. I personally don'= t think this is a great idea even if doable because it also means a crash would lose any changes users made since startup. The other question I was wondering about is how this should behave on a usb key. Is a simple check making sure the window isn't off the screen(s) on th= e new computer and scooting it into place on startup ok? Or would it be nice to have an option to store this data locally on the machine and not in the Gaim prefs file? -Mike |