[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Straw-devel] updated alternate ui layout
From: |
Juri Pakaste |
Subject: |
Re: [Straw-devel] updated alternate ui layout |
Date: |
Thu, 15 Jul 2004 11:42:29 +0300 |
On Thu, 2004-07-15 at 10:18 +0200, Lucas Nussbaum wrote:
> I don't like the idea of having this kind of options in Straw. This
> makes debugging much harder, since you have to know exactly what
> options are being used by the reporter.
Yeah, I don't like adding too many twiddly options myself.
> We should avoid the tentation of listening to each and every user
> suggestion. I've seen cases in another project where somebody asked for
> something and wouldn't even use it.
Sure. I think I'm mostly pretty good at shooting down suggestions. Best
limiter on these is the very limited developer resources. Development
has been fast lately due to me being on a vacation and Finland having
thus far lousy weather this summer, but normally when I'm able to put in
just a few hours a week, it's easy to stay focused on stuff that's
important :-)
> In the specific case of straw, I don't think we should support another
> rendering engine. gtkhtml2 just suits our needs.
I'm not quite sure what you mean here: I don't think we should support
multiple rendering engines either. However, I wouldn't mind dumping
gtkhtml2, once Gecko/Gtk+ integration is good enough. It's not there yet
and I have no idea if it's progressing.
Besides, the choice might be taken out of our hands. If yelp switches
from gtkhtml2 to Gecko - there has been at least talk about this,
although apparently no code yet, at least not in CVS - there's no
guarantee that gtkhtml2 will still be shipped with the desktop. After
all, it's not part of the platform. If that happens, sticking with
gtkhtml2 will be more difficult.
> Concerning UI, it might
> be good to have ONE other option for setups where real estate on screen
> is important. But it should be designed very carefully.
Well, the thing is, these are just the same widgets organized
differently in containers. It wouldn't add any run-time complexity to
support this kind of thing; possibility something at the time of loading
up the UI, but after that, it's just business as usual.
But no need to worry, as I said, it's not going to happen any time soon.
It's a low-priority task.
--
[ Juri Pakaste | address@hidden | http://www.iki.fi/juri/ ]
signature.asc
Description: This is a digitally signed message part