frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Andrew Cagney]

Hello,

The use of "gui" in the frysk name space has been a wart for about as 
long as it has been there :-)  It's the interface, implemented using 
GNOME and not "the graphical user interface".

These two renames will help to clarify that.  (No, I'd not suggest 
changing frysk-gui :-).

Andrew

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Kris Van Hees]

To be slightly pedantic, why not use frysk.ui.gnome and frysk.ui.cli or
similar designations?  Since frysk features both a command line
interface and a graphical interface, it would make sense to organize
them both under a common user interface parent.  That also introduces a
perfect place in the hierarchy for abstract UI features (frysk.ui).

You might also consider actually going with frysk.ui.gui.gnome (though
you might not like long classnames - I am not a fan of them but they do
have their uses in terms of namespace clarity) given that while the
current GUI is implemented using GNOME, there is no reason why an
alternative couldn't be implemented based on any other graphical
toolkit.

	Cheers,
	Kris

On Fri, Jun 15, 2007 at 09:55:39AM -0400, Andrew Cagney wrote:
> Hello,
> 
> The use of "gui" in the frysk name space has been a wart for about as 
> long as it has been there :-)  It's the interface, implemented using 
> GNOME and not "the graphical user interface".
> 
> These two renames will help to clarify that.  (No, I'd not suggest 
> changing frysk-gui :-).
> 
> Andrew
> 

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Andrew Cagney]

Kris Van Hees wrote:
> To be slightly pedantic, why not use frysk.ui.gnome and frysk.ui.cli or
> similar designations?  Since frysk features both a command line
> interface and a graphical interface, it would make sense to organize
> them both under a common user interface parent.  That also introduces a
> perfect place in the hierarchy for abstract UI features (frysk.ui).
>
>   
Or frysk.ui.gnome, frysk.ui.hpd, frysk,ui.eclipse, and frysk.ui.util?  
I've found keeping the hierarchy relatively flat gives a longer shelf 
life, and, for instance, in the case of HPD is it a user interface or a 
component used to build a user interface?

Andrew

PS: UI developers will happily point out that both "CLI" and "GUI" are 
bad :-)

> You might also consider actually going with frysk.ui.gui.gnome (though
> you might not like long classnames - I am not a fan of them but they do
> have their uses in terms of namespace clarity) given that while the
> current GUI is implemented using GNOME, there is no reason why an
> alternative couldn't be implemented based on any other graphical
> toolkit.
>
> 	Cheers,
> 	Kris
>
> On Fri, Jun 15, 2007 at 09:55:39AM -0400, Andrew Cagney wrote:
>   
>> Hello,
>>
>> The use of "gui" in the frysk name space has been a wart for about as 
>> long as it has been there :-)  It's the interface, implemented using 
>> GNOME and not "the graphical user interface".
>>
>> These two renames will help to clarify that.  (No, I'd not suggest 
>> changing frysk-gui :-).
>>
>> Andrew
>>
>>     

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Kris Van Hees]

On Fri, Jun 15, 2007 at 11:04:31AM -0400, Andrew Cagney wrote:
> Kris Van Hees wrote:
> >To be slightly pedantic, why not use frysk.ui.gnome and frysk.ui.cli or
> >similar designations?  Since frysk features both a command line
> >interface and a graphical interface, it would make sense to organize
> >them both under a common user interface parent.  That also introduces a
> >perfect place in the hierarchy for abstract UI features (frysk.ui).
> 
> Or frysk.ui.gnome, frysk.ui.hpd, frysk,ui.eclipse, and frysk.ui.util?  
> I've found keeping the hierarchy relatively flat gives a longer shelf 
> life, and, for instance, in the case of HPD is it a user interface or a 
> component used to build a user interface?

If there is confusion on whether something is a user interface or a
component, then there is a design problem that needs to be resolved
first.  Proper separation of implementation and presentation implies a
strict distinction between the actual user interface and components used
to build it.

But yes, your suggestion for frysk.ui.<id> to capture all user interface
aspects (both abstract on the frysk.ui level, and concrete/final on the
frysk.ui.<id> level) is definitely a good way to go.

> PS: UI developers will happily point out that both "CLI" and "GUI" are 
> bad :-)

Terminology and design tend to clash more often than not.  What matters
is that proper separation is enforced rather than whether something is
named following this or that so-called standard.  The most common
distinction made in the HCI field these days is (not entirely by
surprise) GUI and non-GUI.  The latter covers a very wide range of
output modalities, but they all have in common that they are not based
on a graphical presentation.  

Of course, as with any area that is still actively researched, things
like terminology tend to change every few years.

	Cheers,
	Kris

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Andrew Cagney]

Kris Van Hees wrote:
>
>> Or frysk.ui.gnome, frysk.ui.hpd, frysk,ui.eclipse, and frysk.ui.util?  
>> I've found keeping the hierarchy relatively flat gives a longer shelf 
>> life, and, for instance, in the case of HPD is it a user interface or a 
>> component used to build a user interface?
>>     
>
> If there is confusion on whether something is a user interface or a
> component, then there is a design problem that needs to be resolved
> first.  Proper separation of implementation and presentation implies a
> strict distinction between the actual user interface and components used
> to build it.
>
>   

So we're clear here, even frysk.ui.blah is an unnecessary nesting.  It 
adds no real value.  Or to put it way, my suggestion of the existing 
frysk.cli.hpd was a mistake.

Andrew

> But yes, your suggestion for frysk.ui.<id> to capture all user interface
> aspects (both abstract on the frysk.ui level, and concrete/final on the
> frysk.ui.<id> level) is definitely a good way to go.
>
>   

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Kris Van Hees]

On Fri, Jun 15, 2007 at 12:40:17PM -0400, Andrew Cagney wrote:
> Kris Van Hees wrote:
> >>Or frysk.ui.gnome, frysk.ui.hpd, frysk,ui.eclipse, and frysk.ui.util?  
> >>I've found keeping the hierarchy relatively flat gives a longer shelf 
> >>life, and, for instance, in the case of HPD is it a user interface or a 
> >>component used to build a user interface?
> >
> >If there is confusion on whether something is a user interface or a
> >component, then there is a design problem that needs to be resolved
> >first.  Proper separation of implementation and presentation implies a
> >strict distinction between the actual user interface and components used
> >to build it.
> 
> So we're clear here, even frysk.ui.blah is an unnecessary nesting.  It 
> adds no real value.  Or to put it way, my suggestion of the existing 
> frysk.cli.hpd was a mistake.

I guess we're at opposite ends of the spectrum here, and in all, if you
opt for a more tightly coupled design rather than a clear separation of
user interaction and functionality, I guess a flat hierarchy goes.  I am
just a bit surprised that you would opt not to use the class hierarchy
to bring clarity to how the various packages relate to one another,
which tends to be an advantage regardless of whether you go for a
tightly coupled design or a layered approach.

	Cheers,
	Kris

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Andrew Cagney]

Kris Van Hees wrote:
> I guess we're at opposite ends of the spectrum here, and in all, if you
> opt for a more tightly coupled design rather than a clear separation of
> user interaction and functionality, I guess a flat hierarchy goes.  I am
> just a bit surprised that you would opt not to use the class hierarchy
> to bring clarity to how the various packages relate to one another,
> which tends to be an advantage regardless of whether you go for a
> tightly coupled design or a layered approach.
>
>   
Ah, but Frysk is using the package hierarchy where it adds clarity; for 
instance frysk.proc.live and frysk.proc.dead (nee frysk.proc.ptrace and 
frysk.proc.corefile); or frysk.sys.proc

Andrew

Re: frysk.gui -> frysk.gnome ;; /usr/bin/frysk -> /usr/bin/frysk-gnome

[Kris Van Hees]

On Fri, Jun 15, 2007 at 01:41:27PM -0400, Andrew Cagney wrote:
> Kris Van Hees wrote:
> >I guess we're at opposite ends of the spectrum here, and in all, if you
> >opt for a more tightly coupled design rather than a clear separation of
> >user interaction and functionality, I guess a flat hierarchy goes.  I am
> >just a bit surprised that you would opt not to use the class hierarchy
> >to bring clarity to how the various packages relate to one another,
> >which tends to be an advantage regardless of whether you go for a
> >tightly coupled design or a layered approach.
>
> Ah, but Frysk is using the package hierarchy where it adds clarity; for 
> instance frysk.proc.live and frysk.proc.dead (nee frysk.proc.ptrace and 
> frysk.proc.corefile); or frysk.sys.proc

The same applies for user interfaces.  They are a very important part of
an application, and therefore deserve similar attention.  And as long as
there are questions like whether hpd is a user interface or a component
to build user interfaces with there clearly are issues that remained to
be resolved (well, unless one doesn't care about that kind of thing).

I guess the problem is that I just do not see where frysk.gnome (as you
say, the interface implemented using GNOME) vs frysk.cli.hpd (the
existing command line interface) brings any clarity.  To me, it simply
indicates that there doesn't seem to be any concept of a defined user
interface that is implemented in different ways for different
modalities.  If that is the intent, hey, good enough.  If that is not
the intent, then I'm afraid to admit I do not consider the hierarchy
very clear.

So...  am I right that there is no actual 'interface' in terms of source
code, but rather just two different user interfaces?

	Cheers,
	Kris