Magical User Interface?
Manuel Lemos
: From what i heard, the final version of MUI is even more awesome...
: Forget Gadtools :-)
We all reckon that MUI can generate very beatiful and functional interfaces but
there are two important things that are missing there that keep me from using it:
- No GUI editor. I know, in the future, right? I hope it will be as brilliant
as NextStep's Inteface Builder!
- Generates code that depends on its own shared libaries. I would use and even
pay reasonable money for it, if it would only depend on Commodore's shared
libraries. The fact is I as well most of other programmers that develop
commercial sofwtare, don't want want to develop software to sell that depends
on licensed third party libraries like MUI or ReqTools!
I sure hope that what I said starts making sense in the MUI programmer's mind,
as it didn't last I tried to explain it!
Mark A. Thomas
>
>- No GUI editor. I know, in the future, right? I hope it will be as brilliant
> as NextStep's Inteface Builder!
An interface builder for MUI should be easier to write than GadToolsBox since
the system consists of BOOPSI objects. These objects should be more managable,
from a programming standpoint. However, even though the objects are more
managable, they do have more options to handle, like interobject communication.
>- Generates code that depends on its own shared libaries. I would use and even
> pay reasonable money for it, if it would only depend on Commodore's shared
> libraries. The fact is I as well most of other programmers that develop
> commercial sofwtare, don't want want to develop software to sell that depends
> on licensed third party libraries like MUI or ReqTools!
One idea would be to make the library available as sharable and linkable. This
really depends on how big it is.
--
Mark A. Thomas | "The urgency of our desire to see the SSC completed
mth...@cs.utexas.edu | comes from a sense that without it we may not be able
Programming for | to continue with the great intellectual adventure of
MacroSystemUS | discovering the final laws of nature." -Steven Weinburg
Manuel Lemos
: In article <CB92q...@brigite.ci.ua.pt> etm...@ci.ua.pt (Manuel Lemos) writes:
: >
: >- No GUI editor. I know, in the future, right? I hope it will be as brilliant
: > as NextStep's Inteface Builder!
: An interface builder for MUI should be easier to write than GadToolsBox since
: the system consists of BOOPSI objects. These objects should be more managable,
: from a programming standpoint. However, even though the objects are more
: managable, they do have more options to handle, like interobject communication.
Of coarse, GadTools.library is a sort of crippled interface to intuition and boopsi. It has been improved, but older kickstart users won't benefit from improvements. An unforgiveable limitation of gadtools v37 is that it hasn't not GetAttribut function! Hwo am I supposed to keep track of a cycle or MX gadget state if
I don't know it already? Humpf!
: >- Generates code that depends on its own shared libaries. I would use and even
: > pay reasonable money for it, if it would only depend on Commodore's shared
: > libraries. The fact is I as well most of other programmers that develop
: > commercial sofwtare, don't want want to develop software to sell that depends
: > on licensed third party libraries like MUI or ReqTools!
: One idea would be to make the library available as sharable and linkable. This
: really depends on how big it is.
Offer both possibilities and make the program commercial. Many programmers would
like to use that and would pay for it if necessary, including me!
Jochen Wiedmann
>An unforgiveable limitation of gadtools v37 is that it hasn't not GetAttribut
>function!
GadTools V39 has the GT_GetGadgetAttrs() function.
Jochen
--
Jochen Wiedmann E-Mail: wied...@mailserv.zdv.uni-tuebingen.de
Stephen Kurlow
supposed to achieve regarding boopsi objects?
--
Stephen Kurlow.
Software Engineer, Sydney, Australia. Internet: sku...@socs.uts.edu.au
Stefan Stuntz
|> - Generates code that depends on its own shared libaries. I would use and even
|> pay reasonable money for it, if it would only depend on Commodore's shared
|> libraries. The fact is I as well most of other programmers that develop
|> commercial sofwtare, don't want want to develop software to sell that depends
|> on licensed third party libraries like MUI or ReqTools!
I see your problem. But having the MUI classes as external shared libraries
is the only way for applications to benefit from improvements. For example,
a future MUI release might offer a substantially different slider design,
other imagery, other sizes, other keyboard control. All MUI applications
will automatically adapt to this new design without forcing every programmer
to recompile his source and release a new version.
And I hope that MUI will soon be installed on every machine with Kick 2.x
and above... :-)
Bye, Stefan
Matija Milostnik
>In article <CB92q...@brigite.ci.ua.pt>, etm...@ci.ua.pt (Manuel Lemos) writes:
>|> - Generates code that depends on its own shared libaries. I would use and
>|> even pay reasonable money for it, if it would only depend on Commodore's
>|> shared libraries. The fact is I as well most of other programmers that
>|> develop commercial sofwtare, don't want want to develop software to sell
>|> that depends on licensed third party libraries like MUI or ReqTools!
>
>I see your problem. But having the MUI classes as external shared libraries
>is the only way for applications to benefit from improvements. For example,
!?! The one and only way is to stay compatible with the OS.
(There are a milion way to benefit ofr impovements, but the key
question is how.
>a future MUI release might offer a substantially different slider design,
>other imagery, other sizes, other keyboard control. All MUI applications
>will automatically adapt to this new design without forcing every programmer
>to recompile his source and release a new version.
This holds also true for the case of the prorammer who want to have a
Commmodore shared library compatible GUI builder. The basic idea
behind system libraries is to have a lot of function that can improve
with your system only by upgrading your OS.
We DONT need new and improved third party slider, imagery, etc... What we
need are programs that can upgrade with the system.
If C= decides to do a pink slider, all application will have the pink
slider, in the case of the third party shared libraries we have to
wait for the producer of the code to adapt to this pink slider. But
what if he decides that he wants to have a yellow slider, because he
thinks it is far better that sliced bread. Then on a system with this
you will have a mix of pink and yellow sliders.
Get the picture? :-)
>And I hope that MUI will soon be installed on every machine with Kick 2.x
>and above... :-)
And I hope that Kick 2.x and above will soon be installed on every
machine... :-)
Bye
Matija
>Bye, Stefan
--
Matija Milostnik mat...@amigaphysik.unizh.ch, mat...@avalon.unizh.ch
Du bist mein Glueck. Nicht immer. Aber immer wieder.
Stefan Stuntz
|> If C= decides to do a pink slider, all application will have the pink
|> slider, in the case of the third party shared libraries we have to
|> wait for the producer of the code to adapt to this pink slider. But
|> what if he decides that he wants to have a yellow slider, because he
|> thinks it is far better that sliced bread. Then on a system with this
|> you will have a mix of pink and yellow sliders.
Seems you didn't look at MUI. In my opinion, neither a programmer nor the
operating system shall define how GUI elements shall look. The only
person who knows the best choice is the *user* of an application.
That's what MUI tries to accomplish. The *user* of a MUI application
can decide if he wants to have standard system scrollers or absolutely
fancy designed knobs sliding on a stony background pattern.
Bye, Stefan
Schneider Christian
>can decide if he wants to have standard system scrollers or absolutely
>fancy designed knobs sliding on a stony background pattern.
I couldn't manage to select _no border at all_ around groups. I just don't
like the cluttering of the screen with lots of borders and stuff.
But perhaps the MUI documentation/prefs program wasn't that intuitive after
all ;-)
I see your point about shared libraries but my experiences with proprietary
shared libraries were rather bad (i.e. making my USER:LIBS grow and grow).
Such libraries should a) provide _really_ new functionality to the OS and
b) preferably come from CBM.
Personally, as I'm coadministrating Aminet, I fear lots of uploaded archives
- either all containing the whole MUI library/object set and eating up valuable
disk space and download bandwith
- or not containing all MUI libraries and thus flooding my mailbox with
questions like "the program does not work".
I doubt I will install MUI programs permanently (like I avoided all those
ixemul programs, having to manually 'assign libs: special_libs add' reminds
me of looking for a 'cleaner' program doing the job ;-) Nothing personal,
Markus ;-)).
Just my 0.02$
- Chris
--
Chris Schneider - csch...@amiga.physik.unizh.ch BIX: hschneider IRC: cschneid
It's impossible to enjoy idling thoroughly unless one has plenty of work to do
Per Salmi
: I see your problem. But having the MUI classes as external shared libraries
: is the only way for applications to benefit from improvements. For example,
: a future MUI release might offer a substantially different slider design,
: other imagery, other sizes, other keyboard control. All MUI applications
: will automatically adapt to this new design without forcing every programmer
: to recompile his source and release a new version.
What kind of licence will it be for commercial products using MUI? Can you
give me an example?
: And I hope that MUI will soon be installed on every machine with Kick 2.x
: and above... :-)
And you will get rich... :-)
--
+------------------------------------+-------------------------------------+
| Per Salmi, sa...@paxton.augs.se | /|_ _ _ _ |
| snail-mail: Bjornkarrsgatan 15B:12 | /_||\/||/_ |_| /\/\otorola 68040 |
| S-58251 Linkoping | / || ||\_|| | _ |
| SWEDEN | |_) |
| phone: +46-(0)13-172267 | /_| _ _ _ | icasso II - Gfx! |
| bbs: +46-(0)13-172333 | |(_)(_)(_) |
+------------------------------------+-------------------------------------+
Daniel Murrell Jr.
Stefan,
Do you have any plans to support AmigaE, and if so, how soon?
Dan
--
Danimal on IRC
dj...@ra.msstate.edu
Manuel Lemos
Newsgroups: comp.sys.amiga.programmer
References: <1993Aug13.1...@Informatik.TU-Muenchen.DE>
Stefan Stuntz (stu...@Informatik.TU-Muenchen.DE) wrote:
:
:
: |> - Generates code that depends on its own shared libaries. I would use and even
: |> pay reasonable money for it, if it would only depend on Commodore's shared
: |> libraries. The fact is I as well most of other programmers that develop
: |> commercial sofwtare, don't want want to develop software to sell that depends
: |> on licensed third party libraries like MUI or ReqTools!
:
: I see your problem. But having the MUI classes as external shared libraries
: is the only way for applications to benefit from improvements. For example,
: a future MUI release might offer a substantially different slider design,
: other imagery, other sizes, other keyboard control. All MUI applications
: will automatically adapt to this new design without forcing every programmer
: to recompile his source and release a new version.
How would you feel if the C compiler that you use would demand that the
compiled programs require a certain (possibly large) library installed?
Actually GCC does this, and it's only worthy to keep the highest possible
compatibility with Unix, but 150K is much more than the size of most programs,
and sometimes we just want to use a few features.
I know that providing one single shared library is more confortable for the
developer (you, Stefan Stuntz) than just puting several linkable modules
in a linkable library. It's easier to keep the future compatibility.
But it's not that much a greater effort to provide MUI both ways.
My wishes for MUI:
- provide also linkable code to use within programs.
- provide classes as individual modules to let the programs just use whatever
classes it really needs.
- A interface builder is a must!
Advice:
Make it commercial. People respect more commercial programs than PD/shareware.
: And I hope that MUI will soon be installed on every machine with Kick 2.x
: and above... :-)
Sincerely, I think you should be more concerned in making serious money from
it than just feed your ego. Don't get me wrong, but MUI is already great as
it is, and it's a shame I won't be using it.
Matti Rintala
I'm not Stefan Stuntz, but I'll reply anyway...
On Sat, 14 Aug 1993 21:48:12 GMT,
etm...@ci.ua.pt (Manuel Lemos) said:
-> How would you feel if the C compiler that you use would demand that the
-> compiled programs require a certain (possibly large) library installed?
Well, they do, although those libraries are supplied by Commodore.
-> I know that providing one single shared library is more confortable for the
-> developer (you, Stefan Stuntz) than just puting several linkable modules
-> in a linkable library. It's easier to keep the future compatibility.
I think the future compatability is not the only issue here. Another
reason is the bug fixes. MUI, like most programs, has bugs (I've
already spotted two myself). If MUI was based on linkable libraries,
I'd have to get a bug-fixed version of EVERY PROGRAM THAT USES MUI,
every time a bug-fixed version of MUI is released.
-> My wishes for MUI:
-> - provide also linkable code to use within programs.
As a user I don't agree. I personally wouldn't like fill my HD with
identical code fragments of MUI (which would happen if MUI was a link
library). I wouldn't like to waste my RAM by having identical code
fragments of MUI hanging there. And thirdly I wouldn't like to
download the identical MUI code from ftp sites with every program that
uses MUI (although I may have to anyway, if people include the MUI
libraries with their software packages).
-> - A interface builder is a must!
Well, on this I agree. Although I find designing with pure MUI quite
easy (being a TeX user) :-) .
-> Advice:
-> Make it commercial. People respect more commercial programs than PD/shareware.
I know I don't. Usually the customer service is much poorer with
commercial programs (especially the rate of bug-fix releases).
Secondly, if MUI was commercial, very few would use it, and thus it
wouldn't become popular, even fewer people would use it etc. etc.
--
-------------------------------------------------------------------------------
Matti Rintala bi...@cs.tut.fi
*******************************************************************************
"Time is a drug. Too much of it kills you."(from Small Gods by Terry Pratchett)
Georg Hessmann
[...]
>My wishes for MUI:
>
>- provide also linkable code to use within programs.
I see only disadvantages for this.
(E.g. bugs are fixed in a new MUI release...what about all MUI apps
which would have used link-libs? --> Much traffic on aminet :)
>- provide classes as individual modules to let the programs just use whatever
> classes it really needs.
Look at the MUI distribution. The classes are already individual modules!
And Stefan permits, that you include in your PD/FD/... program only the
classes you really need.
>- A interface builder is a must!
No! It's *so* easy to implement a GUI with MUI (in C)...I think it will be
more work to build it graphically, than with the nice C macros.
Maybe a interface builder like that from NeXT may an improvement, but
it must be *really* good to outrange the C-macros.
>Advice:
>
>Make it commercial. People respect more commercial programs than PD/shareware.
Yes, that's right. :-(
But I hope MUI will stay 'free'. At least free in this term, that
everyone can use it without to pay. (If you don't want to save MUI prefs)
If this wouldn't be the case, I would dissuade every PD/FD programmer
from using MUI. :(
I already think, we have too much shareware. Nearly every bigger (or not)
new program is shareware. Where are the good _free_ programs?
Georg.
--
Georg Heßmann Universitaet Hamburg, FB Informatik
Hess...@Informatik.Uni-Hamburg.De Troplowitz Str. 7, D-22529 Hamburg
<<Nick: Gucky>> Phone: +49 40 4123-6553
Per Salmi
: My wishes for MUI:
:
: - provide also linkable code to use within programs.
And sit back watching the bloat in code size... like MS-Windows
applications... NO THANKS!
: - A interface builder is a must!
That would be nice...
: Advice:
:
: Make it commercial. People respect more commercial programs than PD/shareware.
Possibly in the US but not in Europe, commersial software is more expensive
and has BAD support in most cases, SAS/C is the only software that has an
acceptable level of support.
I would never buy MUI if it was totally commersial.
: : And I hope that MUI will soon be installed on every machine with Kick 2.x
: : and above... :-)
:
: Sincerely, I think you should be more concerned in making serious money from
: it than just feed your ego. Don't get me wrong, but MUI is already great as
: it is, and it's a shame I won't be using it.
I think something like MUI is impossible to sell as a fully commercial
package.
Gustavo Cordova Avila
>I see your point about shared libraries but my experiences with proprietary
>shared libraries were rather bad (i.e. making my USER:LIBS grow and grow).
>Such libraries should a) provide _really_ new functionality to the OS and
>b) preferably come from CBM.
a) they do provide for more functionality, since the OS doesn't have,
say, the docks that toolmanager.library provides, the objects oriented
userinterface thet mui.library provides, the very nice requesters available,
et al.
>Personally, as I'm coadministrating Aminet, I fear lots of uploaded archives
>- either all containing the whole MUI library/object set and eating up valuable
> disk space and download bandwith
>- or not containing all MUI libraries and thus flooding my mailbox with
> questions like "the program does not work".
I think you're drowning in a glass of water, since you could inspect the
archives and remove duplicated information, exchanging it for a note indicating
where to get the MUI package. sounds like a lot, doesn't it? But actual
applications aren't all that much, most uploads are mods, pix, sounds, anims,
demos.
>I doubt I will install MUI programs permanently (like I avoided all those
>ixemul programs, having to manually 'assign libs: special_libs add' reminds
>me of looking for a 'cleaner' program doing the job ;-) Nothing personal,
>Markus ;-)).
I have that in my HDAssigns file, since I already have to do tons of
assignations, I keep them in their own file. Much neater. Keeps the User-
Startup clean.
>Just my 0.02$
and mine also.
-Gus
Colas Nahaboo
writes:
> How would you feel if the C compiler that you use would demand that the
> compiled programs require a certain (possibly large) library installed?
I use gcc a lot, and I think it is *GREAT*. I mean, I'd rather have a shared
150K than add 30-40k to each of a small utility.
Besides, do you actually know a commercial program that do not make you install
a dozen of more of support files? (help, tutorials, modules)
> - provide also linkable code to use within programs.
*NO*. As a user, I want to be able to upgrade my applications with
bugfixed/improved MUI classes
> - provide classes as individual modules to let the programs just use whatever
> classes it really needs.
Isn't it the case now already? (Classes/MUI)
> - A interface builder is a must!
No, I dont think so. IB are just icing on the cake, and do solve only the easy
problems, not the hard ones (I know, we do an IB for X windows in our team).
> Make it commercial. People respect more commercial programs than
> PD/shareware.
Be careful. If it is commercial, how are you going to have demo versions and
convince people to use it?
I am saying this since in France, there as been a product named UIK (User
Interface Kit) doing what does UIK, and much much more (as claimed by its
author, Jean Michel Forgeas), for a long time (nearly 2 years I think). The
problem: there was no evaluation version, since it is very difficult to design
one for these kind of libraries.
The result: nobody knows of UIK. MUI may wipe it into oblivion, even if UIK is
better than MUI (UIK seems much more efficient, and runs in 1.3 or 2.0), just
because you can try MUI at no charge. With this in mind, I think Stephan choose
the right way to distribute MUI!
--
Colas Nahaboo, Koala (Bull Research). Full sig. by: finger co...@indri.inria.fr
Mike Neylon
>In article <CBrr8...@brigite.ci.ua.pt> etm...@ci.ua.pt (Manuel Lemos) writes:
>[...]
>>My wishes for MUI:
>>
>>- provide also linkable code to use within programs.
>
>I see only disadvantages for this.
>(E.g. bugs are fixed in a new MUI release...what about all MUI apps
>which would have used link-libs? --> Much traffic on aminet :)
AND you will be able to keep your own code size down with shared libs.
>>- A interface builder is a must!
>
>No! It's *so* easy to implement a GUI with MUI (in C)...I think it will be
>more work to build it graphically, than with the nice C macros.
>
>Maybe a interface builder like that from NeXT may an improvement, but
>it must be *really* good to outrange the C-macros.
>
What I would like to see is something that just takes in the interface
structure, ignoring any non-graphical options, and displays an
example of what that would look like on the screen. That way, it
would allow you check to see if your tree structure is correct.
>
>>Advice:
>>
>>Make it commercial. People respect more commercial programs than PD/shareware.
>
>Yes, that's right. :-(
>But I hope MUI will stay 'free'. At least free in this term, that
>everyone can use it without to pay. (If you don't want to save MUI prefs)
>
A better way to have release the package in order to make it more
sensible is for the MUI prefs to be completely usable (no disfunctions),
and to attach SOME shareware to developes...thats mainly what this
package is for. I dont see any reason why if I get a shareware program
using MUI that I have to pay both the program's shareware and MUI's
shareware fee to have a completely functional program.
BTW: I need to know if my messages are posted or not. Please respond
via email before 2: pm EST today (8/16/93) if you see this message!
Thank you!
--
-----------------------------------------------------------------------------
Mike Neylon | phone: 216-433-4000
NASA Lewis Research Center |
Cleveland, Ohio 44135 | email: smne...@lerc.nasa.gov
-----------------------------------------------------------------------------
Schneider Christian
>a) they do provide for more functionality, since the OS doesn't have,
> say, the docks that toolmanager.library provides, the objects oriented
> userinterface thet mui.library provides, the very nice requesters available,
I disagree but I don't think we should argue on that. I don't have any
toolmanager dependent program (and use a simpler workbench dock which suits
my needs). One can have nice and font sensitive user interfaces without MUI.
I consider everything except ASL requester silly. Feel free to call me a
purist but I think great ideas can be killed by excessive implementations.
>and remove duplicated information, exchanging it for a note indicating
>where to get the MUI package. sounds like a lot, doesn't it? But actual
I definitely won't! I'm doing this in my free time and won't spend more and
more time adding/removing parts to/from archives.
MUI can make 250k out of 50k. I consider this a reason not to include it.
Per Salmi
: In article <al158305.745529285@academ01> al15...@academ01.mty.itesm.mx (Gustavo Cordova Avila) writes:
: >a) they do provide for more functionality, since the OS doesn't have,
: > say, the docks that toolmanager.library provides, the objects oriented
: > userinterface thet mui.library provides, the very nice requesters available,
: I disagree but I don't think we should argue on that. I don't have any
: toolmanager dependent program (and use a simpler workbench dock which suits
: my needs). One can have nice and font sensitive user interfaces without MUI.
: I consider everything except ASL requester silly. Feel free to call me a
: purist but I think great ideas can be killed by excessive implementations.
Are you doing any of these font sensitive GUIs on your own? No? I thought
so... Otherwise you would have liked MUI. Making a GUI to be font sensitive
is a real pain in the ass without MUI and the Amiga can benefit from the
produtitivity boost that MUI provides in the form of FAST development of
serious applications.
MUI is perfect for smaller applications as people often has a lot of these
hanging aroud in the WBStartup drawer for example...
Maybe I see the font sensitivity thing in a brighter light than others
because it is really bad to run things with hardcoded topaz 8 fonts on a
1280x1024 WorkBench screen.
/salmi
Cedric Beust
csch...@avalon.physik.unizh.ch (Schneider Christian) writes:
>One can have nice and font sensitive user interfaces without MUI.
Oh yeah? Then show me just ONE application that allows EVERY
gadget to be controlled via keyboard (even Cycle, Pushbuttons,
etc...).
If you find one, is it font-sensitive? Can it be resized?
And still keep a normal look?
Honestly, I can't even find one application that simply matches
the first point, let alone all of them (this is something that
only the Amiga misses : Motif, Windows, System 7, all allow
keyboard control).
--
Cedric BEUST, be...@sa.inria.fr, Bull Research Koala proj, MessageBus & xforum
Pho:(33) 93.65.78.11(.65 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.
Bruce - Dawson
would be rather leery about depending on MUI. Whenever you decide to use
a new tool you have to look at how dependent you will be on the supplier,
and how reliable the supplier will be. If the tool ias a terminal
program, then you won't get burned too badly if it stops working. If the
tool is the user interface for the program that pays your bills, then you
have to be very careful. The limited payments for shareware typically do
mean limited guarantee of future complaints being addressed.
Of course even with commercial software there is certainly no
guarantee, but with a Commodore supplied GUI you can be pretty sure that
it will remain compatible with most all legal software.
Much of what I said above applies to all shareware, not specifically
MUI. Don't get me wrong - I LOVE shareware, I'm just leery of depending
on it too much.
The above mentioned bug was an incorrect emulation of the V38+ asl
multi-select.
Bil Irving
: >One can have nice and font sensitive user interfaces without MUI.
: Oh yeah? Then show me just ONE application that allows EVERY
: gadget to be controlled via keyboard (even Cycle, Pushbuttons,
: etc...).
Oh come off it, there are loads! Term 3.4 for one. Everything I write is
capable of being controlled entirely through keyboard also.
: If you find one, is it font-sensitive? Can it be resized?
: And still keep a normal look?
Term is font-sensitive, but can't be resized.. but there are others which do
allow it (try DFA 1.23 for instance).
: Honestly, I can't even find one application that simply matches
: the first point, let alone all of them (this is something that
: only the Amiga misses : Motif, Windows, System 7, all allow
: keyboard control).
Well you're not looking too hard then are you! :-)
Bil