Picon

widget size independant to screen resolution

Hello list,

sorry to break radio silence :-), I hope Y wakes up some time soon.

The reason I'm writing is to express my desire for all graphical 
environments. Unfortunately this feature is not fully implemented 
anywhere (to my knowledge) but I'd love to see it in the window server 
of the future ;-).

In a few words what I want is that widget size should be independant to 
screen resolution.
	Actually, by saying widget I mean everything drawn on screen: menus, 
buttons, toolbars, tasbar, window margins, borders, title bars e.t.c., 
even common text.
	And by saying independant to screen resolution I certainly don't expect 
everything to have the same size in every screen at every resolution. 
What I consider fairly easy is drawing everything like now, with default 
size, but giving the user an option using a slider to change the "widget 
size". When changing this variable everything mentioned before should 
change size alltogether.

As for the implementation, the general idea is to multiply the 
dimensions of everything drawn on screen (e.g. font size) with a float 
variable, initially set to 1 and changed with the previous slider. There 
is a problem with the graphics inside widgets, but can be solved either 
using exlusively scalable graphics, or bitmaps properly resized.

The usefulness is obvious to whoever hates giantic widgets (desktops 
like kindergarden :-) ) and is stuck with a low-res TFT.

(Continue reading)

Matthew A. Nicholson | 10 Oct 09:41
Favicon

Re: widget size independant to screen resolution

I like this idea very much.  Of course it still may be necessary to specify a 
more fixed size or over ride this type of positioning/sizing.

Dimitrios Apostolou wrote:
> Hello list,
> 
> sorry to break radio silence :-), I hope Y wakes up some time soon.
> 
> The reason I'm writing is to express my desire for all graphical 
> environments. Unfortunately this feature is not fully implemented 
> anywhere (to my knowledge) but I'd love to see it in the window server 
> of the future ;-).
> 
> In a few words what I want is that widget size should be independant to 
> screen resolution.
>     Actually, by saying widget I mean everything drawn on screen: menus, 
> buttons, toolbars, tasbar, window margins, borders, title bars e.t.c., 
> even common text.
>     And by saying independant to screen resolution I certainly don't 
> expect everything to have the same size in every screen at every 
> resolution. What I consider fairly easy is drawing everything like now, 
> with default size, but giving the user an option using a slider to 
> change the "widget size". When changing this variable everything 
> mentioned before should change size alltogether.
> 
> As for the implementation, the general idea is to multiply the 
> dimensions of everything drawn on screen (e.g. font size) with a float 
> variable, initially set to 1 and changed with the previous slider. There 
> is a problem with the graphics inside widgets, but can be solved either 
> using exlusively scalable graphics, or bitmaps properly resized.
(Continue reading)

Jacob O'Reilly | 10 Oct 15:21
Picon

Re: widget size independant to screen resolution

Sounds much like the scaling in .NET's Windows Forms.  Your widgets grow 
proportionately to the Windows font size setting (e.g. Large Fonts or 
arbitrary user preference.)  Works especially well when you use the layout 
mechnisms like anchoring and docking.

----- Original Message ----- 
From: "Matthew A. Nicholson" <matt <at> matt-land.com>
To: "Dimitrios Apostolou" <jimis <at> gmx.net>
Cc: <y-devel <at> y-windows.org>
Sent: Sunday, October 10, 2004 4:41 AM
Subject: Re: [Y-devel] widget size independant to screen resolution

>I like this idea very much.  Of course it still may be necessary to specify 
>a more fixed size or over ride this type of positioning/sizing.
>
> Dimitrios Apostolou wrote:
>> Hello list,
>>
>> sorry to break radio silence :-), I hope Y wakes up some time soon.
>>
>> The reason I'm writing is to express my desire for all graphical 
>> environments. Unfortunately this feature is not fully implemented 
>> anywhere (to my knowledge) but I'd love to see it in the window server of 
>> the future ;-).
>>
>> In a few words what I want is that widget size should be independant to 
>> screen resolution.
>>     Actually, by saying widget I mean everything drawn on screen: menus, 
>> buttons, toolbars, tasbar, window margins, borders, title bars e.t.c., 
>> even common text.
(Continue reading)

Arpad Borsos | 16 Oct 11:12

Activity

Come on guys.
This is not how the project should be like.
There hasn't been any activity in the last 2-3 month.
I know that Andrew is busy with some things but then release some new 
code at least. And stop yelling at people that they are to stupid to set 
up arch. I'm a complete linux n00b and i managed to get the latest 
release from arch. But that doesnt really help me if there hasn't been 
any activity in the arch tree since july.
So please at least commit your changes to arch that other people can 
play with the code and that i can test it.
I had a compile error some time ago which i could resolve with a little 
help from a friend but since i have switched to gcc 3.4 i'm totaly out 
of luck. Unfortunately i can't code C++ :( See the Build Config Page for 
more details.
As i mentioned before, i can't help with coding but if you need someone 
who knows good PHP and XHTML let me know ;) PHP bindings would be realy 
cool though.

So long. I hope there will be some changes in the future.

--

-- 
________________________________
MfG Arpad Borsos aka "Swatinem"
IRC: irc://de.quakenet.org/swatinemz
________________________________
Reclaim Your Inbox! - Mozilla Thunderbird
http://www.mozilla.org/products/thunderbird/

Take Back the Web! - Mozilla Firefox
http://www.mozilla.org/products/firefox/
(Continue reading)

Phil Willoughby | 16 Oct 13:43

Re: Activity

Quoting Arpad Borsos <arpad <at> gamesweb.com>:
> So please at least commit your changes to arch that other people can
> play with the code and that i can test it.

You seem to be under the impression that there is some secret hidden codebase
somewhere in which changes have been made. There isn't.  Everyone's busy.

> I had a compile error some time ago which i could resolve with a little
> help from a friend but since i have switched to gcc 3.4 i'm totaly out
> of luck. Unfortunately i can't code C++ :( See the Build Config Page for
> more details.

Where's that page then?  As a complaint, this is probably the most useless
information ever.  If you send the last few lines of your make output (from the
point it executed the compiler to the point make noticed the error) to the list
there's a moderate chance you might get some help.

This patch fixes some bugs in code which may or may not be related to your
problem (against markbt <at> efaref.net--2004 Y--devel--0.2--patch-54):

===begin===
--- orig/Y/main/config.c
+++ mod/Y/main/config.c
@@ -199,7 +199,7 @@
   long int i = strtol(*c, &end, 0);

   /* Must be terminated with whitespace */
-  if (!isspace(*c))
+  if (!isspace(*end))
     return false;
(Continue reading)

richard | 16 Oct 14:01

Re: Activity

On Sat, 2004-10-16 at 12:43, Phil Willoughby wrote: 
> Quoting Arpad Borsos <arpad <at> gamesweb.com>:
> > So please at least commit your changes to arch that other people can
> > play with the code and that i can test it.
> 
> You seem to be under the impression that there is some secret hidden codebase
> somewhere in which changes have been made. There isn't.  Everyone's busy.

Given Suffield's comment recently:

> Development activity is roughly inversely proportional to time
> spent farting about on IRC, for pretty much any project.

... I assumed development was leaping ahead.

Richard

Brandon Black | 16 Oct 17:31
Picon

Re: Activity

Regardless of whether any work is being done by anyone, or being made
available to the public, you can't really fault anyone for open source
work, or chide them for not making their own efforts available and
easy for you to use right now.  If you're itching to work on Y, then
by all means, grab the latest source you can find and work on it
yourself.

On Sat, 16 Oct 2004 13:01:05 +0100, richard <richard <at> playford.net> wrote:
> On Sat, 2004-10-16 at 12:43, Phil Willoughby wrote:
> > Quoting Arpad Borsos <arpad <at> gamesweb.com>:
> > > So please at least commit your changes to arch that other people can
> > > play with the code and that i can test it.
> >
> > You seem to be under the impression that there is some secret hidden codebase
> > somewhere in which changes have been made. There isn't.  Everyone's busy.
> 
> Given Suffield's comment recently:
> 
> > Development activity is roughly inversely proportional to time
> > spent farting about on IRC, for pretty much any project.
> 
> ... I assumed development was leaping ahead.
> 
> Richard
> 
>

james | 17 Oct 00:21

Arch tutorial article.

http://www.linuxjournal.com/article.php?sid=7671

I saw this article while browsing around and thought I'd bring it up since
a lot of people have either problems or fear of arch. It seems to explain
things a little simpler than the arch-tutiral
(http://gnuarch.org/tutorial/html/arch.html).

Cheers,
James

Matthew Sackman | 17 Oct 01:00

Re: Arch tutorial article.

On Sat, Oct 16, 2004 at 10:21:57PM -0000, james <at> grickle.org wrote:
> http://www.linuxjournal.com/article.php?sid=7671

Goodness, someone's finally invented a time machine.

Matthew
--

-- 
Matthew Sackman

BOFH excuse #149:
Dew on the telephone lines.

Arpad Borsos | 17 Oct 10:52

Arch tutorial article.

I dont realy think that Arch is the problem. I found it realy easy to 
install.
The problem is, that there hasn't been any commits in since july.
Or is there somewhere some secret archive that is not documented in the 
wiki?

--

-- 
________________________________
MfG Arpad Borsos aka "Swatinem"
IRC: irc://de.quakenet.org/swatinemz
________________________________
Reclaim Your Inbox! - Mozilla Thunderbird
http://www.mozilla.org/products/thunderbird/

Take Back the Web! - Mozilla Firefox
http://www.mozilla.org/products/firefox/
________________________________


Gmane