Johnny wants to program a linux GUI app.
Hadron Quark
A little excercise in Linux advocacy here for you - I certainly hope to
have a few things clarified as its all very, very confusing at the moment.
Little Johnny, who has been a windows programmer for years, is familiar
with gui windowing systems, C and C++. At a push he could be bothered to
learn some Perl or whatever else. However, he doesn't want to do
anything in Java.
He has a great idea for a killer GUI app which involves a form of
wordprocessor, bitmapped graphics display and audio.
He wonders which APIs/Toolhits he should use, which Desktop Environments
he should design it for. His brother told him Gnome sucked and that KDE
was better. He is confused. He wants his app to run on all Linux systems
the same.
He has worked for years on a new rendering code path which speeds up 32
bit colour masking by a factor of 8. He wishes to use this in his new
app - but obviously doesnt want to hand out the algorithms source code
in his app which he plans to sell.
Discuss.
ed
Hadron Quark <qadro...@geemail.com> wrote:
> A little excercise in Linux advocacy here for you - I certainly hope
> to have a few things clarified as its all very, very confusing at the
> moment.
>
> Little Johnny, who has been a windows programmer for years, is
> familiar with gui windowing systems, C and C++. At a push he could be
> bothered to learn some Perl or whatever else. However, he doesn't want
> to do anything in Java.
>
> He has a great idea for a killer GUI app which involves a form of
> wordprocessor, bitmapped graphics display and audio.
yeah yeah, all rudimentary stuff that's on google.
> He wonders which APIs/Toolhits he should use, which Desktop
> Environments he should design it for. His brother told him Gnome
> sucked and that KDE was better. He is confused. He wants his app to
> run on all Linux systems the same.
then johnny should google tk.
> He has worked for years on a new rendering code path which speeds up
> 32 bit colour masking by a factor of 8. He wishes to use this in his
> new app - but obviously doesnt want to hand out the algorithms source
> code in his app which he plans to sell.
then johnny distributes the binary. but don't expect anyone to run a
download and execute the binary, we don't do that here. johnny should
look at ./configure && make && sudo make install. if the app is that
kill then he might go to the fsf consortium and ask for funding so that
they can buy the algo off him, if it really is of such benefit.
--
Regards, Ed :: http://www.s5h.net
proud unix hacker
Brought down the Walls of Jericho with a spirited Hadooken.
Hadron Quark
> On Sat, 14 Oct 2006 12:20:10 +0200
> Hadron Quark <qadro...@geemail.com> wrote:
>
>> A little excercise in Linux advocacy here for you - I certainly hope
>> to have a few things clarified as its all very, very confusing at the
>> moment.
>>
>> Little Johnny, who has been a windows programmer for years, is
>> familiar with gui windowing systems, C and C++. At a push he could be
>> bothered to learn some Perl or whatever else. However, he doesn't want
>> to do anything in Java.
>>
>> He has a great idea for a killer GUI app which involves a form of
>> wordprocessor, bitmapped graphics display and audio.
>
> yeah yeah, all rudimentary stuff that's on google.
You have no idea what he wants to do - these are just the UIs.
>
>> He wonders which APIs/Toolhits he should use, which Desktop
>> Environments he should design it for. His brother told him Gnome
>> sucked and that KDE was better. He is confused. He wants his app to
>> run on all Linux systems the same.
>
> then johnny should google tk.
Err, why? This is not discussing. The back end will be in C/C++ for
effiency - he will wish to create his own control classes no dount for
the UI. Most real apps do.
>
>> He has worked for years on a new rendering code path which speeds up
>> 32 bit colour masking by a factor of 8. He wishes to use this in his
>> new app - but obviously doesnt want to hand out the algorithms source
>> code in his app which he plans to sell.
>
> then johnny distributes the binary. but don't expect anyone to run a
> download and execute the binary, we don't do that here. johnny should
Whose "we" and wheres "here"?
> look at ./configure && make && sudo make install. if the app is that
> kill then he might go to the fsf consortium and ask for funding so that
> they can buy the algo off him, if it really is of such benefit.
So, you basically think he can give up trying to sell his app?
--
To reduce printing costs, we have sent you only the forms you may need based on
what you filed last year.
ed
Hadron Quark <qadro...@geemail.com> wrote:
> ed <e...@noreply.com> writes:
>
> > On Sat, 14 Oct 2006 12:20:10 +0200
> > Hadron Quark <qadro...@geemail.com> wrote:
> >
> >> A little excercise in Linux advocacy here for you - I certainly
> >hope > to have a few things clarified as its all very, very confusing
> >at the > moment.
> >>
> >> Little Johnny, who has been a windows programmer for years, is
> >> familiar with gui windowing systems, C and C++. At a push he could
> >be > bothered to learn some Perl or whatever else. However, he
> >doesn't want > to do anything in Java.
> >>
> >> He has a great idea for a killer GUI app which involves a form of
> >> wordprocessor, bitmapped graphics display and audio.
> >
> > yeah yeah, all rudimentary stuff that's on google.
>
> You have no idea what he wants to do - these are just the UIs.
>
> >
> >> He wonders which APIs/Toolhits he should use, which Desktop
> >> Environments he should design it for. His brother told him Gnome
> >> sucked and that KDE was better. He is confused. He wants his app to
> >> run on all Linux systems the same.
> >
> > then johnny should google tk.
>
> Err, why? This is not discussing. The back end will be in C/C++ for
> effiency - he will wish to create his own control classes no dount for
> the UI. Most real apps do.
then he can write whatever he wants. there are many snippets of
pre-written code that does meet those vague requirements. if he wishes
to write it all from scratch then johnny is fully within his rights to
do so.
> >> He has worked for years on a new rendering code path which speeds
> >up > 32 bit colour masking by a factor of 8. He wishes to use this in
> >his > new app - but obviously doesnt want to hand out the algorithms
> >source > code in his app which he plans to sell.
> >
> > then johnny distributes the binary. but don't expect anyone to run a
> > download and execute the binary, we don't do that here. johnny
> > should
>
> Whose "we" and wheres "here"?
we, here are the majority of free os users. very few people bother with
anything that is distributed in binary format except for some very odd
exceptions, such as hardware drivers.
the majority of software distributed in compiled format without source
code fails within a year.
the same can be said for most protocols which are closed, where they are
not shoved down users throats continuously they often fail.
> > look at ./configure && make && sudo make install. if the app is that
> > kill then he might go to the fsf consortium and ask for funding so
> > that they can buy the algo off him, if it really is of such benefit.
>
> So, you basically think he can give up trying to sell his app?
he can try, he just wont get far. why would someone who has a free OS go
and pay for some app that?
--
Regards, Ed :: http://www.ednevitable.co.uk
proud bash person
Light goes the speed of Chuck Norris.
Hadron Quark
Ed, you are missing my point. I asked what toolkits/APIs to use - not
which OSS code to copy.
>
>> >> He has worked for years on a new rendering code path which speeds
>> >up > 32 bit colour masking by a factor of 8. He wishes to use this in
>> >his > new app - but obviously doesnt want to hand out the algorithms
>> >source > code in his app which he plans to sell.
>> >
>> > then johnny distributes the binary. but don't expect anyone to run a
>> > download and execute the binary, we don't do that here. johnny
>> > should
>>
>> Whose "we" and wheres "here"?
>
> we, here are the majority of free os users. very few people bother with
> anything that is distributed in binary format except for some very odd
> exceptions, such as hardware drivers.
>
> the majority of software distributed in compiled format without source
> code fails within a year.
>
> the same can be said for most protocols which are closed, where they are
> not shoved down users throats continuously they often fail.
>
>> > look at ./configure && make && sudo make install. if the app is that
>> > kill then he might go to the fsf consortium and ask for funding so
>> > that they can buy the algo off him, if it really is of such benefit.
>>
>> So, you basically think he can give up trying to sell his app?
>
> he can try, he just wont get far. why would someone who has a free OS go
> and pay for some app that?
At least you are honest.
--
Specifications subject to change without notice.
ed
Hadron Quark <qadro...@geemail.com> wrote:
> > then he can write whatever he wants. there are many snippets of
> > pre-written code that does meet those vague requirements. if he
> > wishes to write it all from scratch then johnny is fully within his
> > rights to do so.
>
> Ed, you are missing my point. I asked what toolkits/APIs to use - not
> which OSS code to copy.
i said, tk.
#include <tk.h>
if he is hell bent on using kde/gnome then they have their own api's,
but i would recommend using something that is as light weight as
possible. as mentioned on other programming lists however, splitting the
work and the interface apart through IPC and into two/three tiers has
many benefits, thus many different window apis could be used and porting
the code is much less work. if this is beyond johnny then i expect the
world does not see this as such a killer app.
--
Regards, Ed :: http://www.bsdwarez.net
proud bash person
Chuck Norris once raped a rhino, just to show how badass he can be.
Rick
> On Sat, 14 Oct 2006 13:15:17 +0200
> Hadron Quark <qadro...@geemail.com> wrote:
(snip)
>> So, you basically think he can give up trying to sell his app?
>
> he can try, he just wont get far. why would someone who has a free OS go
> and pay for some app that?
You might ask Novell or Transgaming that same question.
--
Rick
Rick
>
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do anything
> in Java.
>
> He has a great idea for a killer GUI app which involves a form of
> wordprocessor, bitmapped graphics display and audio.
>
> He wonders which APIs/Toolhits he should use, which Desktop Environments
> he should design it for. His brother told him Gnome sucked and that KDE
> was better. He is confused. He wants his app to run on all Linux systems
> the same.
<http://portland.freedesktop.org/wiki/>
>
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8. He wishes to use this in his new app
> - but obviously doesnt want to hand out the algorithms source code in his
> app which he plans to sell.
BSD License.
>
> Discuss.
--
Rick
Jamie Hart
>
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
How exactly is setting up a strawman to show linux in a bad light linux
advocacy?
Do you really think linux users are stupid enough to believe you, or are you
just spreading FUD for the benefit of windows users?
<Snip same old tired bullshit>
Rick
> ed <e...@noreply.com> writes:
>
>> On Sat, 14 Oct 2006 13:15:17 +0200
>> Hadron Quark <qadro...@geemail.com> wrote:
(snip)
>>> So, you basically think he can give up trying to sell his app?
>>
>> he can try, he just wont get far. why would someone who has a free OS go
>> and pay for some app that?
>
> At least you are honest.
... because he gives you the answer you want.
--
Rick
ed
Novel have done 'killer' graphics work for linux desktops that we all
know and love...
--
Regards, Ed :: http://s5h.net/qf
just another python hacker
Chuck Norris writes only in the first person because thats the only
person that matters to anyone.
Hadron Quark
So you cant answer the question?
I'm serious.
How owuld you choose which APIs or toolkits to use?
I want you to instruct me. Advocate.
Because I'll be damned if I can see a concistent approach.
--
...[Linux's] capacity to talk via any medium except smoke signals.
-- Dr. Greg Wettstein, Roger Maris Cancer Center
Hadron Quark
> On Sat, 14 Oct 2006 13:49:34 +0200
> Hadron Quark <qadro...@geemail.com> wrote:
>
>> > then he can write whatever he wants. there are many snippets of
>> > pre-written code that does meet those vague requirements. if he
>> > wishes to write it all from scratch then johnny is fully within his
>> > rights to do so.
>>
>> Ed, you are missing my point. I asked what toolkits/APIs to use - not
>> which OSS code to copy.
>
> i said, tk.
>
> #include <tk.h>
I know. With zero backup. With zero explanation. This is not instructive
enough to make a base foundation decision on.
>
> if he is hell bent on using kde/gnome then they have their own api's,
he isnt. he wants to know what advantages there are by siding with one
over the other. Stop moving the goalposts.
> but i would recommend using something that is as light weight as
> possible. as mentioned on other programming lists however, splitting
> the
Lightweight as possible? Define this please. At what cost? He needs a
feature rich UI with the ability to subclass UI controls and write
specific input control handling code.
> work and the interface apart through IPC and into two/three tiers has
> many benefits, thus many different window apis could be used and
> porting
What "man different window apis"? I think you're bluffing. Be more specific.
> the code is much less work. if this is beyond johnny then i expect the
> world does not see this as such a killer app.
A lot of words, but very few answers. Johnny knows how to partition apps
- any half decent programmer does. He isnt asking for architecture
advice in airy fairy high level - he's asking WHAT APIs he should use
for a powerful UI which is concistent across Linux versions using
different windowing managers.
Can you answer that? I cant. And I am trying to.
--
Waving away a cloud of smoke, I look up, and am blinded by a bright, white
light. It's God. No, not Richard Stallman, or Linus Torvalds, but God. In
a booming voice, He says: "THIS IS A SIGN. USE LINUX, THE FREE UNIX SYSTEM
FOR THE 386.
-- Matt Welsh
Rick
> Jamie Hart <use...@jhart.ath.cx> writes:
>
>> Hadron Quark wrote:
>>
>>
>>> A little excercise in Linux advocacy here for you - I certainly hope to
>>> have a few things clarified as its all very, very confusing at the
>>> moment.
>>>
>> How exactly is setting up a strawman to show linux in a bad light linux
>> advocacy?
>>
>> Do you really think linux users are stupid enough to believe you, or are
>> you just spreading FUD for the benefit of windows users?
>>
>> <Snip same old tired bullshit>
>
> So you cant answer the question?
>
> I'm serious.
>
> How owuld you choose which APIs or toolkits to use?
>
> I want you to instruct me. Advocate.
>
> Because I'll be damned if I can see a concistent approach.
Portland.
--
Rick
Rex Ballard
Hadron Quark wrote:
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
And why doesn't he want to use Java? Java provides a consistent
platform that will allow him to create his application and still be
able to run it on Windows as well as Linux..
Java has nice toolkits, good support, and can easily be deployed.
> He has a great idea for a killer GUI app which involves a form of
> wordprocessor, bitmapped graphics display and audio.
Nothing terribly difficult there.
> He wonders which APIs/Toolkits he should use, which Desktop Environments
> he should design it for.
> His brother told him Gnome sucked
Sounds like his brother worked for Microsoft. After all, GNOME (GTK)
can't be published under strict nondisclosures, by Microsoft, the way
the Qt (KDE) code can.
> KDE was better. He is confused.
KDE is very good. The qt toolkit supports both Windows and Linux, and
permits commercial licensing of the code. KDE and Qt were created by
TrollTech, which are part of the Canopy group. The same folks who
brought you Caldera - BEFORE it got hijacked by Daryl McBride and his
Microsoft Buddies.
> He wants his app to run on all Linux systems the same.
Best to use an interpretive language such as Python, PERL/TK, or Ruby.
All of these have support for APIs that can be consistent across any
number of platforms. You might also want to reconsider your position
on Java. The TK toolkit was originally developed for TCL, the language
used on AOL before HTML became so popular. TCL is also pretty quick
and easy to learn, but PERL and PYTHON have better OSS Library support.
Keep in mind that X11 uses 'frames' and 'processes', which make it
possible to mix and match toolkits, if you are really feeling strangely
driven to "try everything".
The one thing I DON'T reccomend, is trying to implement a complex
application in C or C++. It's a bit like welding the trunk shut on the
car. It might not get as dusty, but when you need to make upgrades and
maintenance, like changing the oil, it gets messy. In the same way,
scripted languages like PERL and Python allow you to combine compiled
libraries with the loosely coupled interfaces, which can be easily
enhanced.
This is especially nice if you are looking to generate something that
can easily be "tailored" to the customer's needs. The "off the rack
suits usually don't fit right, the pants either hang over the shoes, or
the socks show so much you look like you're about to wade through high
water. The same is true of software. You think you have the perfect
app, and you give it to the customer, and he wants smaller or larger
fonts (he reads postage stamps or uses low res displays, or he uses
high res displays and need bifocals). The most frequently used
applications end up being 3 levels deep, and the customer put them up
at the top, while the initialization routines, which were important to
developers, need to move down a level or two.
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8.
Normally, the common practice is to use X11, or OpenGL to send messages
to the display server, which then does the rendering.
> He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
That's pretty low-level coding there Quark. Most folks don't get into
bit twiddling unless they are coding for a specific chipset. I would
suggest that if the code is that much faster, that he consider writing
an XServer driver. This is what ATI did. They offer the OSS version,
which is slow but functional, but they also have a "binary only"
ultra-high performance version that provides really good high speed
rendering in both 2D and 3D graphics.
The graphics themselvs are rendered by calling the xlib functions,
which then send messages to the Xserver, which then translates those
messages into chipset commands. The nice thing is that the application
doesn't have to wait for things like vertical sync signals. Most X11
displays on modern chipsets can render 2D graphics faster than they can
be displayed, and can render complex 3d graphics in near-real-time.
Linux also supports clustering technology which can be used to further
accelerate the calculations used in 3D rendering.
The Alsa interface lets the application send audio bits to an audio
"server" which then feeds to the audio circutry. Again, the server can
mix and match from multiple sources, and can support multichannel
output. This is all configurable using either configuration files or
graphical interfaces such as YAST. More complex mixer software is also
available for those who want studio quality audio production, but it is
more expensive than what is included for free with most Linux
distributions.
> Discuss.
ed
Hadron Quark <qadro...@geemail.com> wrote:
> A lot of words, but very few answers. Johnny knows how to partition
> apps - any half decent programmer does. He isnt asking for
> architecture advice in airy fairy high level - he's asking WHAT APIs
> he should use for a powerful UI which is concistent across Linux
> versions using different windowing managers.
>
> Can you answer that? I cant. And I am trying to.
linux works with an without a ui of any sort, so one cannot guarantee
that the app will work in every circumstance, nor can one guarantee that
the libraries will be available for the app. hence the tk specification,
it's got fewest dependencies, doesn't require much, and it's got great
character.
anything else has greater dependencies etc and therefore less likely to
run ootb.
this is a pointless discussion, it's like arguing over which layout
manager is best for java apps. best option is to avoid the ui completely
and just do whatever crunch work is required at the command line and
save a lot of time. any ui that is required can be down at a browser
level for 90% of cases.
--
Regards, Ed :: http://www.bsdwarez.net
proud perl person
There was no 'final plague' that God sent down upon Pharoah. Mr. T
just got hungry.
flatfish+++
>
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
>
> He has a great idea for a killer GUI app which involves a form of
> wordprocessor, bitmapped graphics display and audio.
>
> He wonders which APIs/Toolhits he should use, which Desktop Environments
> he should design it for. His brother told him Gnome sucked and that KDE
> was better. He is confused. He wants his app to run on all Linux systems
> the same.
It depends..
Which one of the 400+ Linux distributions does he want to write for?
Oh, silly me, I see he wants his app to run on all Linux systems.
Good luck...............
flatfish+++
> How exactly is setting up a strawman to show linux in a bad light linux
> advocacy?
Linux doesn't need any help showing itself in a bad light.
It does quite fine all by itself.
> Do you really think linux users are stupid enough to believe you, or are you
> just spreading FUD for the benefit of windows users?
>
> <Snip same old tired bullshit>
Well it's a known fact that Linux zealots have far more religion than
brains.
Ian Hilliard
If your little Johnnie knows MFC, he should look at wxwidgets.org, which is
the better MFC than MFC.
Ian
spi...@freenet.co.uk
> Jamie Hart <use...@jhart.ath.cx> writes:
>> Hadron Quark wrote:
>>
>>>
>>> A little excercise in Linux advocacy here for you - I certainly hope to
>>> have a few things clarified as its all very, very confusing at the moment.
>>>
>> How exactly is setting up a strawman to show linux in a bad light linux
>> advocacy?
>>
>> Do you really think linux users are stupid enough to believe you, or are you
>> just spreading FUD for the benefit of windows users?
>>
>> <Snip same old tired bullshit>
> So you cant answer the question?
> I'm serious.
> How owuld you choose which APIs or toolkits to use?
He wants it to run on all linux, so that excludes KDE.
All linux systems that run X these days tend to include gtk, so that seems
the sensible option, alternatively he could try SDL seeing as he wants to
include multimedia components. SDL would also aid in making it cross
platform so it could be compiled for linux, windows or MacOSX.
He'd need to be a bit more specific about what HE wants.
--
______________________________________________________________________________
| spi...@freenet.co.uk | |
|Andrew Halliwell BSc(hons)| "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" |
| in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
| Computer Science | - Father Jack in "Father Ted" |
------------------------------------------------------------------------------
Thufir
>> So, you basically think he can give up trying to sell his app?
>
> he can try, he just wont get far. why would someone who has a free OS go
> and pay for some app that?
Which doesn't preclude selling other types of applications. There's
commercial software in the linux world, and, as IBM, Novell, Redhat and
Sun get more involved with linux the potential for third party apps,
closed source and commercial, only increases. The fly in the ointment is:
which kind of apps?
In a way, there's room for WordPerfect, MS Word, Lotus et. al. to battle
it out in linux land. There might even be room for all of the above, and
more, but this is an admittedly specious example in that the niche is
already filled with OSS variants such that it's impractical to try.
The more interesting question is:
what niches could be filled with commercial software? Johnny could make a
bundle, he just has to find that "killer app," so to speak, for which
there's demand but no supply.
The only example I can think of are games, but there you run into a
chicken-or-egg problem due to a small user base. OTOH, if there were
games for Linux from the big players, then there might be more Linux users :)
-Thufir
Thufir
>
> Hadron Quark wrote:
>> A little excercise in Linux advocacy here for you - I certainly hope to
>> have a few things clarified as its all very, very confusing at the moment.
>>
>> Little Johnny, who has been a windows programmer for years, is familiar
>> with gui windowing systems, C and C++. At a push he could be bothered to
>> learn some Perl or whatever else. However, he doesn't want to do
>> anything in Java.
>
> And why doesn't he want to use Java? Java provides a consistent
> platform that will allow him to create his application and still be
> able to run it on Windows as well as Linux..
>
> Java has nice toolkits, good support, and can easily be deployed.
>
>> He has a great idea for a killer GUI app which involves a form of
>> wordprocessor, bitmapped graphics display and audio.
>
> Nothing terribly difficult there.
[...]
Were the proposed idea more interesting then the OP might be on to
something :)
Why not mono? Can mono apps run on windows? Or even Mac?
-Thufir
Peter Köhlmann
> On Sat, 14 Oct 2006 13:35:39 +0000, Rick wrote:
>
>
>> Portland.
>
> Oregon or Maine?
And flatfish again shows off his utter cluelessness
--
Windows is just the instable version of Linux for users who are too
dumb to handle the real thing
Roy Culley
<egr6n3$lde$01$1...@news.t-online.com>,
Peter =?UTF-8?B?S8O2aGxtYW5u?= <peter.k...@t-online.de> writes:
> flatfish+++ wrote:
>
>> On Sat, 14 Oct 2006 13:35:39 +0000, Rick wrote:
>>
>>
>>> Portland.
>>
>> Oregon or Maine?
>
> And flatfish again shows off his utter cluelessness
Absolutely, clearly it is Portland UK. :-)
--
Security is one of those funny things. You can talk about being "more"
secure, but there's no such thing. A vulnerability is a vulnerability, and
even one makes you just as insecure as anyone else. Security is a binary
condition, either you are or you aren't. - Funkenbusch 1 Oct 2006
Rick
> On Sat, 14 Oct 2006 13:35:39 +0000, Rick wrote:
>
>
>> Portland.
>
> Oregon or Maine?
Buy a clue.
--
Rick
Jamie Hart
> Jamie Hart <use...@jhart.ath.cx> writes:
>
>> Hadron Quark wrote:
>>
>>>
>>> A little excercise in Linux advocacy here for you - I certainly hope to
>>> have a few things clarified as its all very, very confusing at the
>>> moment.
>>>
>> How exactly is setting up a strawman to show linux in a bad light linux
>> advocacy?
>>
>> Do you really think linux users are stupid enough to believe you, or are
>> you just spreading FUD for the benefit of windows users?
>>
>> <Snip same old tired bullshit>
>
> So you cant answer the question?
>
Sure I can, He can develop two versions of his app, one GTK and one QT, that
covers gnome and KDE.
If he is lazy, like a windows programmer, he can use wxWindows and have a
single version for kde/gnome/windows/osX.
Now, how about answering my question. How is a feeble attempt at showing
linux in a bad light advocacy?
> I'm serious.
>
You're a wintroll, so no one takes you seriously.
> How owuld you choose which APIs or toolkits to use?
>
I'd develop for what I use. Personally that would be using the QT API. You
see, anyone who is serious about programming for linux, already uses it and
knows what they like, so they program for that.
If they sell the program, they may later decide to include a version for
other widget sets.
You pretending that they need a single API for all widget sets is just a
strawman, you know it, I know it, and now everyone who searches google
knows it.
> I want you to instruct me. Advocate.
>
Ah, you want me to advocate? Fine. I do it quite often, you should try it
some time.
> Because I'll be damned if I can see a concistent approach.
>
But then, that would spoil your trolling, wouldn't it?
Linonut
> The one thing I DON'T reccomend, is trying to implement a complex
> application in C or C++.
C++ was /designed/ for complex applications.
--
Windows XP is like a box of chocolates --
you never know when the steel bolts are going to spring out and
plunge straight through both cheeks.
Roy Culley
<6vWdnTTo9vcIpqzY...@comcast.com>,
Linonut <lin...@bone.com> writes:
> After takin' a swig o' grog, Rex Ballard belched out this bit o' wisdom:
>
>> The one thing I DON'T reccomend, is trying to implement a complex
>> application in C or C++.
>
> C++ was /designed/ for complex applications.
And Xlib, Xt, olit, motif, ... were written in C. Come to think of it
so was Unix. In fact doesn't C have something rather special to do
with Unix. :-)
Now Windows would appear to be written in basic by a bunch of
Ignoramuses in comparison. :-)
cc
Hadron Quark wrote:
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
>
So Little Johnny wants to write an app that's completely portable
across distros, but doesn't want to use Java? Sounds like Johnny should
go back to CS101 and learn to use the language that best solves the
problem. This a pretty stupid example, but hell I shouldn't be
surprised.
flatfish+++
> flatfish+++ wrote:
>
>> On Sat, 14 Oct 2006 13:35:39 +0000, Rick wrote:
>>
>>
>>> Portland.
>>
>> Oregon or Maine?
>
> And flatfish again shows off his utter cluelessness
Oh silly me!
I guess you guys were talking about Portland Cement.
My mistake.
ed
"cc" <scat...@hotmail.com> wrote:
and whats wrong with python/perl, both are more portable than java,
which has licence restrictions.
--
Regards, Ed :: http://www.bsdwarez.net
proud java hacker
The A-Team, in fact, chronicles President T's diplomatic visits to
the US in the 1980s. They were an unparalleled success.
ed
Thufir <hawat....@gmail.com> wrote:
> On Sat, 14 Oct 2006 11:44:51 +0000, ed wrote:
> [...]
> >> So, you basically think he can give up trying to sell his app?
> >
> > he can try, he just wont get far. why would someone who has a free
> > OS go and pay for some app that?
>
> Which doesn't preclude selling other types of applications. There's
> commercial software in the linux world, and, as IBM, Novell, Redhat
> and Sun get more involved with linux the potential for third party
> apps, closed source and commercial, only increases. The fly in the
> ointment is:
> which kind of apps?
>
> In a way, there's room for WordPerfect, MS Word, Lotus et. al. to
> battle it out in linux land. There might even be room for all of the
> above, and more, but this is an admittedly specious example in that
> the niche is already filled with OSS variants such that it's
> impractical to try.
this happened about 5 years ago. there was once a http://linux.corel.com
site, and they had their own distro... dont know what has happened to
that now. it was reasonable.
why bother though? could they really produce something as good as
openoffice?
> The more interesting question is:
>
> what niches could be filled with commercial software? Johnny could
> make a bundle, he just has to find that "killer app," so to speak, for
> which there's demand but no supply.
that's right. everything has been done already on the command line. gui
is just for people to have multiple terminal windows.
> The only example I can think of are games, but there you run into a
> chicken-or-egg problem due to a small user base. OTOH, if there were
> games for Linux from the big players, then there might be more Linux
> users :)
we have unreal tournament and a bunch of others. they just dont know
such wicked fun games are here.
--
Regards, Ed :: http://s5h.net/qf
proud unix hacker
ed
flatfish+++ <flat...@linuxmail.org> wrote:
> It depends..
>
> Which one of the 400+ Linux distributions does he want to write for?
>
> Oh, silly me, I see he wants his app to run on all Linux systems.
>
> Good luck...............
why would it be such a problem? many programs work just fine in binary
distributed format.
for example
#include <stdio.h>
#include <stdlib.h>
int main( int argc, char *argv[] ) {
return( EXIT_SUCCESS );
}
... why should that, in binary format, not run on one of the given
distros? at best there could be a glibc issue, but i don't see one. all
depends what it's linked to so building it as a static binary should
prevent that, albeit, making the binary a bit bigger.
there really isn't much of an issue.
another example would be the aol instant messenger, that runs just fine
on any linux distro, and it's about 5 years old.
--
Regards, Ed :: http://s5h.net/qf
just another linux person
Vin Diesel owns 15 out of the world's 18 Faberge Eggs. He describes
the other 3 as 'tacky, worthless pieces of plastic crap'.
John A. Bailo
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8. He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
>
> Discuss.
Algorithm does not equal "source code".
Johnny's innovation is the algorithm. He should patent this ASAP if he
wants to license it. The implementation should be irrelevant.
--
Texeme Construct
http://texeme.com
Camping Pics: http://www.texeme.com/Deschutes.html
nrbal...@yahoo.com
Hadron Quark wrote:
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
>
> wordprocessor, bitmapped graphics display and audio.
>
> he should design it for. His brother told him Gnome sucked and that KDE
> the same.
>
GTK is used by GNOME, but is not dependent on any specific operating
system or Desktop Environment. If the code used to create your
application is not dependent on any specific platform, it could be run
by any user.
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8. He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
>
A closed-source binary may work, but there would be much more
responsibility placed upon the developer to make sure that the
application would run correctly on whatever platform the user chooses
to install it.
7
>
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years,
Well there you go, he's and idiot.
The best thing to do is hire some GNU/Linux engineers
and let them do the work for you because a true windope
programmer is bound to be lost when it comes to understanding basic
open source programming principles and ideas.
More business for GNU/Linux houses and less for windopes.
Sounds like a clever plan.
ray
>
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
>
> He has a great idea for a killer GUI app which involves a form of
> wordprocessor, bitmapped graphics display and audio.
>
> He wonders which APIs/Toolhits he should use, which Desktop Environments
> he should design it for. His brother told him Gnome sucked and that KDE
> was better. He is confused. He wants his app to run on all Linux systems
> the same.
>
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8. He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
>
> Discuss.
You'll have to tell Johnny that Linux is all about choice. Just because
you develop a program with a KDE or Gnome toolbox does not mean that it
won't run on a machine with a different one. Tell him to take his pick.
I'd suggest he try out the options and use what he likes best. I've used
gtk for several small projects because it suited me. I used to do a lot of
development with X/Motif (which will require a Motif runtime environment
to be installed, as I recall).
Tim Smith
Hadron Quark <qadro...@geemail.com> wrote:
> He wonders which APIs/Toolhits he should use[...]
Qt. Besides being a terrific environment, it will let him make his app
for Linux, Windows, and OS X, maximizing his market. He'll need to use
the paid version of Qt to make a closed-source commercial app, but it is
worth it.
--
--Tim Smith
nrbal...@yahoo.com
Or, as mentioned before, use GTK+ and you will get the same result at
no cost.
![[H]omer's profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWMQWyYwHeIwxhG3nGUeGWmLQD0R8TeZrvdWDiv5-2S_z3rHg=s40-c)
[H]omer
>> A little excercise in Linux advocacy here for you - I certainly
>> hope to have a few things clarified as its all very, very confusing
>> at the moment.
What exactly is so confusing; the fact that there are multiple widget
toolkits available for Linux? What about all the different toolkits
for Windows (MFC, WTL, SmartWin++, Borland's Object Windows Library &
Visual Component Library, Windows .Net Forms) ... is *that* also too
"confusing" for you?
>> Little Johnny, who has been a windows programmer for years
What, is this guy a midget or something?
>> is familiar with gui windowing systems, C and C++. At a push he
>> could be bothered to learn some Perl or whatever else.
You mean Perl/Tk?
>> However, he doesn't want to do anything in Java.
Oh darn it ... that limits his choices down to several dozen then.
>> He has a great idea for a killer GUI app
Isn't that an Apple trademark? "Killer App" ... ROTFLMAO!!!
>> which involves a form of wordprocessor, bitmapped graphics display
>> and audio.
IOW ... PowerPoint/OOo-Presenter. Looks like this "killer app" really
has it's work cut out for it, especially as one of its competitors is
Free, and the other one is made by the world's biggest commercial
software vendor.
>> He wonders which APIs/Toolhits he should use, which Desktop
>> Environments he should design it for.
It's amazing; you claim to use Linux and yet you obviously don't have
the first clue about the way widget toolkits are implemented in
X. Funny how I can run KDE apps under Gnome, and vice versa, or even
run Qt and GTK+ apps under Fluxbox and Xfce. The answer is support
libraries (yes just like Windows), but then a guru like you already
knew that, didn't you?
>> His brother told him Gnome sucked and that KDE was better. He is
>> confused. He wants his app to run on all Linux systems the same.
> then johnny should google tk.
Yes, likewise tk has runtime libs, just like Qt and GTK+ ... and any
other toolkit.
>> He has worked for years on a new rendering code path which speeds
>> up 32 bit colour masking by a factor of 8.
Is it as good as Cairo or Anti-Grain Geometry? It better be, otherwise
it looks like he's just wasted all those "years".
>> He wishes to use this in his new app - but obviously doesnt want to
>> hand out the algorithms source code in his app which he plans to
>> sell.
Oh obviously.
Of course he better check in with the patents office first, and make
sure that either Microsoft or Adobe haven't already 0wn3d his
brilliant ideas. While he's at it, maybe he better do some market
research to determine if there is in fact any *demand* for yet another
proprietary rendering library, when the market is already flooded with
them, including a stack of Free ones. Yup, it had better be "killer"
indeed.
> then johnny distributes the binary. but don't expect anyone to run a
> download and execute the binary, we don't do that here.
Yup; it's not like there aren't any commercial apps for Linux, it's
just that whatever benefits they offer (if any) are extremely marginal
compared to the best of the FOSS offerings.
Take GEAR Pro for Linux, for example. Last time I checked, it retailed
at $799 ... for a (get this) a *Disc burning application* !!!!
Holy crap!
'Nuf said.
I'll buy commercial games, no problem, but then they don't typically
run into hundreds of dollars. And I will (and do) happily pay for
services (subscriptions), but to pay hundreds for something that has
an (often *better*) Free equivalent, is just stupid.
> johnny should look at ./configure && make && sudo make install.
Johnny should just use Qt for a pretty GUI, give me the source (under
NDA) and let me roll a binary RPM for him, with all the necessary deps
set for support libs. That way, installation and dependency tracking
is automated by the disto's installer (e.g. RPM, dpkg, etc.). No
rocket scientists need apply.
Of course, since this is a proprietary commercial application, I will
have to charge a fee. It'll probably only take about an hour, but I
don't charge for fractions of one day, so I'll need to bill Johnny for
the whole day @ £500 ($928). Hope that's OK for him.
> if the app is that kill then he might go to the fsf consortium and
> ask for funding so that they can buy the algo off him, if it really
> is of such benefit.
I can just see the FSF Hurd (herd) stampeding to the door with
excitement at the prospect.
--
K.
http://slated.org - Slated, Rated & Blogged
.----
| Gates' Law: Every 18 months, the speed of software halves.
`----
Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.16-1.2133_FC5
04:40:39 up 119 days, 4:57, 3 users, load average: 2.02, 2.09, 1.84
Tim Smith
nrbal...@yahoo.com wrote:
> > Qt. Besides being a terrific environment, it will let him make his app
> > for Linux, Windows, and OS X, maximizing his market. He'll need to use
> > the paid version of Qt to make a closed-source commercial app, but it is
> > worth it.
> >
>
> Or, as mentioned before, use GTK+ and you will get the same result at
> no cost.
According to the relevant page at gtk.org, the OS X port is "not yet
finished or usable for mainstream use".
--
--Tim Smith
Peter Kai Jensen
Hash: SHA1
nrbal...@yahoo.com wrote:
>> Qt. Besides being a terrific environment, it will let him make his
>> app for Linux, Windows, and OS X, maximizing his market. He'll need
>> to use the paid version of Qt to make a closed-source commercial app,
>> but it is worth it.
>
> Or, as mentioned before, use GTK+ and you will get the same result at
> no cost.
Having programmed with both GTK+ and QT, I must say that GTK+ is not
what I would classify as a terrific environment, from a programmers
point of view. QT is IMHO much smoother to use and very
well-structured.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
iD8DBQFFMfw8d1ZThqotgfgRAh83AJ4nww4VnO4EUlHba2YXJEbsb4wCUwCdF1LZ
S6XXbsHODAj3QqWMOZUUk+s=
=geA+
-----END PGP SIGNATURE-----
--
PeKaJe
<ahzz_> i figured 17G oughta be enough.
Hadron Quark
> On Sat, 14 Oct 2006 12:08:47 -0400
> flatfish+++ <flat...@linuxmail.org> wrote:
>
>> It depends..
>>
>> Which one of the 400+ Linux distributions does he want to write for?
>>
>> Oh, silly me, I see he wants his app to run on all Linux systems.
>>
>> Good luck...............
>
> why would it be such a problem? many programs work just fine in binary
> distributed format.
>
> for example
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main( int argc, char *argv[] ) {
> return( EXIT_SUCCESS );
> }
>
> ... why should that, in binary format, not run on one of the given
> distros? at best there could be a glibc issue, but i don't see one. all
> depends what it's linked to so building it as a static binary should
> prevent that, albeit, making the binary a bit bigger.
>
> there really isn't much of an issue.
>
> another example would be the aol instant messenger, that runs just fine
> on any linux distro, and it's about 5 years old.
Ed, with all due respect, you really have no idea about what you talk.
Yes, the above program would work. But the use of toolkits & gui
guidelines seems to have gone whistleing over your head. Its why I
mentioned wordprocessor type functionality and something to do with
audio & graphics. You do know there are different APIs that one can use
for GUI interfaces dont you? Which result in totally different user
interfaces? never mind the differences in guidelines for Gnome v KDE
apps. This is what I'm getting at.
--
Used with permission.
JEDIDIAH
> On Sat, 14 Oct 2006 12:20:10 +0200, Hadron Quark wrote:
>
>>
>> A little excercise in Linux advocacy here for you - I certainly hope to
>> have a few things clarified as its all very, very confusing at the moment.
>>
>> with gui windowing systems, C and C++. At a push he could be bothered to
>> anything in Java.
>>
>> He has a great idea for a killer GUI app which involves a form of
>> wordprocessor, bitmapped graphics display and audio.
>>
>> was better. He is confused. He wants his app to run on all Linux systems
>> the same.
>
> It depends..
>
> Which one of the 400+ Linux distributions does he want to write for?
>
> Oh, silly me, I see he wants his app to run on all Linux systems.
>
> Good luck...............
...especially considering that Linux runs on more than just PCs.
Linux will run on IBM's RISC kit, IBM's mainframes, Sun's RISC kit,
DEC's RISC kit (assumming you can find it), Old PPC Macs, Old 030 Macs and
SGI's old RISC kit.
For a single processor family, you could package up all of your
libraries Apple style. Vendors like Oracle don't seem to have much problem
running on "any linux". You could also do a static link.
If you're really serious about running on "ANY Linux" then you
distribute user linkable code, user compilable code or interpreted code.
Java would be handy there.
--
The social cost of suing/prosecuting individuals |||
for non-commercial copyright infringement far outweighs / | \
the social value of copyright to begin with.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
JEDIDIAH
...then just do what Windows programmers do:
Include the dependencies.
> mentioned wordprocessor type functionality and something to do with
> audio & graphics. You do know there are different APIs that one can use
> for GUI interfaces dont you? Which result in totally different user
> interfaces? never mind the differences in guidelines for Gnome v KDE
> apps. This is what I'm getting at.
If you were a real programmer, even just a Windows programmer,
this problem wouldn't seem so intractable to you.
Aquila Deus
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
Perl is a dying language and not worth to learn.
>
> He has a great idea for a killer GUI app which involves a form of
> wordprocessor, bitmapped graphics display and audio.
>
> He wonders which APIs/Toolhits he should use, which Desktop Environments
> he should design it for. His brother told him Gnome sucked and that KDE
> was better. He is confused. He wants his app to run on all Linux systems
> the same.
Most gui apps are written in c/gtk; he could also use c++/gtkmm, or
mono/gtk#.
Qt/KDE has much better documents and a better style/theme engine API,
but it forces app to use GPL, and 1) qt3 is too old and lacks several
critical things, 2) qt4 is great but nobody installs it yet.
>
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8. He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
It wouldn't matter. HW accel rules and he should just use the Render
extension for grahpics operations.
>
> Discuss.
The Ghost In The Machine
<qadro...@geemail.com>
wrote
on Sat, 14 Oct 2006 12:20:10 +0200
<87d58vw...@geemail.com>:
>
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
>
> wordprocessor, bitmapped graphics display and audio.
>
> He wonders which APIs/Toolhits he should use, which Desktop Environments
> he should design it for. His brother told him Gnome sucked and that KDE
> was better. He is confused. He wants his app to run on all Linux systems
> the same.
>
> bit colour masking by a factor of 8. He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
>
Which ones would he use on Windows?
Linux has several, as you've pointed out; however, they
may have some issues integrating with one another unless
one subinvokes ("system()"). I'd have to look. Bonobo
is a Gnome solution; I don't know the KDE variant and I
don't know that much about Bonobo.
For its part Windows has DCOM/ActiveX, which AIUI will
allow one document to include objects handled by some
other program or DLL.
As for bitmapped graphics display -- DirectX is the obvious
choice on Windows, since not only can one do bitmaps, but
one can do pseudo-3D as well; it's a very popular gaming
interface. OpenGL does much the same on Linux.
If one does not want pseudo-3D, then most of the work can
be done using native widgets in either Gtk or Qt.
The toolkits provide simple editors but I don't know
regarding more complex word processors.
As for the GPL/LGPL license -- no worries about that
unless he modifies a GPL component, in which case the
modifications should be submitted back to the code
repository, using his name of course.
--
#191, ewi...@earthlink.net
Useless C++ Programming Idea #40490127:
for(;;) ;
The Ghost In The Machine
<e...@noreply.com>
wrote
on Sat, 14 Oct 2006 12:01:31 GMT
<20061014125850.10215a14@ed-desktop>:
> On Sat, 14 Oct 2006 13:49:34 +0200
> Hadron Quark <qadro...@geemail.com> wrote:
>
>> > then he can write whatever he wants. there are many snippets of
>> > pre-written code that does meet those vague requirements. if he
>> > wishes to write it all from scratch then johnny is fully within his
>> > rights to do so.
>>
>> Ed, you are missing my point. I asked what toolkits/APIs to use - not
>> which OSS code to copy.
>
> i said, tk.
>
> #include <tk.h>
This could get interesting. In Tcl/Tk one can either
look at the holistic approach, and integrate Tcl/Tk into
one's application, or the integrationalist approach,
and integrate pieces of one's application into Tcl/Tk.
The latter is probably somewhat easier (it's mostly
command registration/implementation), and allows for more
flexibility, though I'm not sure if Tcl/Tk can support a
full word processor (though Tk's text widget does allow for
"tags", which can allow for click-through, font changes,
and coloring of text; one can also include images and
arbitrary widgets such as buttons). Tcl 8 also supports
objects, though I don't know how well.
Also, Tcl is brain-dead as languages go; Python might be a
slightly better choice were it up to the language proper.
However, I'm not as up on Python's capabilities, although
it does have a GUI as well. I think one can also register
foreign C++ code into Python.
If one really wants to go this route, C#/Gtk# might be of
interest as well. However, I'm spoiled by Eclipse and
Monodevelop needs more work. :-) (I don't know if
plans for Eclipse will include C# support or not. And
then there's the Microsoft patent issue.)
>
> if he is hell bent on using kde/gnome then they have their own api's,
> but i would recommend using something that is as light weight as
> possible. as mentioned on other programming lists however, splitting the
> work and the interface apart through IPC and into two/three tiers has
> many benefits, thus many different window apis could be used and porting
> the code is much less work. if this is beyond johnny then i expect the
> world does not see this as such a killer app.
>
There is the possibility that the world sees Windows as
a dying app. :-) However, it's not dead yet.
--
#191, ewi...@earthlink.net
People think that libraries are safe. They're wrong. They have ideas.
(Also occasionally ectoplasmic slime and cute librarians.)
The Ghost In The Machine
<spi...@freenet.co.uk>
wrote
on Sat, 14 Oct 2006 16:49:39 GMT
<vqe704-...@ridcully.ntlworld.com>:
> Hadron Quark <qadro...@geemail.com> did eloquently scribble:
>>>> certainly hope to have a few things clarified as its
>>>> all very, very confusing at the moment.
>>>>
>>> a bad light linux advocacy?
>>>
>>> Do you really think linux users are stupid enough to believe you,
>>> or are you just spreading FUD for the benefit of windows users?
>>>
>>> <Snip same old tired bullshit>
>
>> So you cant answer the question?
>
>
>> How owuld you choose which APIs or toolkits to use?
>
ObHuh: Huh?
Someone explain that to me real slowly. :-) KDE runs
quite well on Gentoo Linux, and presumably on Kubuntu,
Fedora, and SuSE as well. (I suspect it also runs on
Ubuntu but Ubuntu is Gnome-based.)
> All linux systems that run X these days tend to include
> gtk, so that seems the sensible option, alternatively he
> could try SDL seeing as he wants to include multimedia
> components. SDL would also aid in making it cross
> platform so it could be compiled for linux, windows or MacOSX.
I'm not sure SDL does a lot for widgeting. For those
who remember Apollo DOMAIN computers, SDL sounds a lot
like "borrow-display" mode, and while SDL can play sound
and/or maybe music (I've not gotten it to work yet, but
there are hints it can do CD audio and waveforms) it's
primarily focused on OpenGL and bitmap graphics, with
events suitable for gaming, as opposed to things such as
buttons, scrollbars, and text display.
>
> He'd need to be a bit more specific about what HE wants.
Agreed.
The Ghost In The Machine
<r...@nodomain.none>
wrote
on Sat, 14 Oct 2006 22:09:01 +0200
<tns704-...@dog.did.it>:
> begin risky.vbs
> <6vWdnTTo9vcIpqzY...@comcast.com>,
> Linonut <lin...@bone.com> writes:
>> After takin' a swig o' grog, Rex Ballard belched out this bit o' wisdom:
>>
>>> The one thing I DON'T reccomend, is trying to implement a complex
>>> application in C or C++.
>>
>> C++ was /designed/ for complex applications.
>
> And Xlib, Xt, olit, motif, ... were written in C. Come to think of it
> so was Unix. In fact doesn't C have something rather special to do
> with Unix. :-)
>
> Now Windows would appear to be written in basic by a bunch of
> Ignoramuses in comparison. :-)
>
I'm not sure I'd be quite so harsh. C is a sports car
which can be easily overturned by those who don't know
how to steer; it also lacks amenities such as package
management, threading support, and object persistence --
or, for that matter, objects period; the best it can do
without extensive implementation of one's own API is
fwrite(&structure, 1, sizeof(&structure), fp), and
that has lots of problems if one changes machines.
But given the right conditions and careful driving, one
can expect very good performance.
C++ is a sports SUV with some stabilizers and a
roll bar (exception handling) but still can tip over
a little too easily. C++ also has a more powerful
engine with additional capabilities such as limited
RTTI, exception handling, and operator overloading.
However, there are some minor incompatibilities if
one exchanges seats from one SUV to another (ports code
from one vendor to another).
Java is a tank, but under certain conditions the engine
has to garbage-collect, which can slow it down, and still
does not have padded seating such as first-level function
declarations. (Most people don't seem to even notice, and
it does very well in the mud, on the road, and even in
deep forests.)
LISP is the only language I know of that has such, though
others have mentioned Haskell. Since LISP looks like a
typographer's nightmare with all the parenthesis -- or,
if one prefers, a Convert-A-Car (Professor Pat Pending) [*],
though one might apply that to Smalltalk as well.
Smalltalk might have first-level method declarations but
I'd have to look, and unfortunately Smalltalk is a bit
outside the norm (well, so was Pat Pending) -- and I for
one would hope that eventually it won't be, but there's no
real standard for it yet AFAIK (though Squeak is probably
the best known implementation).
C# appears to be a modified truck with some armor plating
that looks a bit like a tank. :-)
Basic is an inflatable go-kart, but surprisingly enough
that's enough for many applications, unless there's sharp
sticks in the vicinity. (Just ask any Zork player. :-))
And yes, there's a Basic implementation on Linux,
if one can stand the animated blue lobster -- Gambas.
(There's gotta be a way to shut off that thing.)
The main problem with C and C++ is buffer overflows are
not easily caught; this appears to be the primary cause
of the security vulnerabilities in Windows. Admittedly,
this is not a complete explanation (Unix and Linux are also
written in C), but I for one wonder if Microsoft is running
its schedules backwards, whereas Linux runs them forwards.
In other words, Microsoft needs things by a certain date
and suffers schedule slip; Linux sells no code before its
time, when it's ready, able, and mature enough.
A lot of companies appear to have that problem. :-)
For its part Unix was a research project, IIRC, and therefore
not subject to deadlines as such, at least at first.
[*] http://en.wikipedia.org/wiki/Wacky_Races, (c) 1968-1970
Hanna-Barbera Productions, but has probably since been
renewed. The amusing thing: the Bouldermobile won the
most races. Go fig.
--
#191, ewi...@earthlink.net
Useless C++ Programming Idea #2239120:
char *p; char *q = p; strcpy(p,q);
spi...@freenet.co.uk
>> He wants it to run on all linux, so that excludes KDE.
> ObHuh: Huh?
> Someone explain that to me real slowly. :-) KDE runs
> quite well on Gentoo Linux, and presumably on Kubuntu,
> Fedora, and SuSE as well. (I suspect it also runs on
> Ubuntu but Ubuntu is Gnome-based.)
All linuxes don't have KDE installed, on account of it being rather
ginormous. That's what I meant. Not that KDE didn't work on any linux
systems, just that is might not be installed. KDE's support libs are much
bigger than gtk's.
>> All linux systems that run X these days tend to include
>> gtk, so that seems the sensible option, alternatively he
>> could try SDL seeing as he wants to include multimedia
>> components. SDL would also aid in making it cross
>> platform so it could be compiled for linux, windows or MacOSX.
> I'm not sure SDL does a lot for widgeting.
That's the problem, I suppose. I'm not sure how well SDL works with other
toolkits either. I heard one person who writes for a project say it and gtk
were mutually exclusive due to the event loops used by GTK clashing with
those used by SDL...
--
______________________________________________________________________________
| spi...@freenet.co.uk | "Are you pondering what I'm pondering Pinky?" |
|Andrew Halliwell BSc(hons)| |
| in | "I think so brain, but this time, you control |
| Computer Science | the Encounter suit, and I'll do the voice..." |
------------------------------------------------------------------------------
Bob Hauck
> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> did
> eloquently scribble:
>>> He wants it to run on all linux, so that excludes KDE.
>
>> ObHuh: Huh?
>
>> Someone explain that to me real slowly. :-) KDE runs quite well on
>> Gentoo Linux, and presumably on Kubuntu, Fedora, and SuSE as well.
>> (I suspect it also runs on Ubuntu but Ubuntu is Gnome-based.)
>
> All linuxes don't have KDE installed, on account of it being rather
> ginormous. That's what I meant. Not that KDE didn't work on any linux
> systems, just that is might not be installed. KDE's support libs are
> much bigger than gtk's.
Let's be fair when discussing the ginormousness of things:
KDE <==> Gnome
Qt <==> GTK
IOW, it isn't fair to compare KDE to GTK alone. Qt plays the analgous
role in KDE that GTK plays in Gnome. Similarly, as there are GTK apps
that don't use Gnome things like Bonobo and gconfd, there are also Qt
apps that don't use kdelibs.
Most users of Gnome or KDE will have at least the base library of the
other desktop installed, but often not the whole thing.
--
-| Bob Hauck
-| Have you had enough of George Bush yet?
-| http://www.haucks.org/
TheLetterK
> On 14 Oct 2006 13:32:16 -0700
> "cc" <scat...@hotmail.com> wrote:
>
>> Hadron Quark wrote:
>>> A little excercise in Linux advocacy here for you - I certainly hope
>>> to have a few things clarified as its all very, very confusing at
>>> the moment.
>>>
>>> Little Johnny, who has been a windows programmer for years, is
>>> familiar with gui windowing systems, C and C++. At a push he could
>>> be bothered to learn some Perl or whatever else. However, he doesn't
>>> want to do anything in Java.
>>>
>> So Little Johnny wants to write an app that's completely portable
>> across distros, but doesn't want to use Java? Sounds like Johnny
>> should go back to CS101 and learn to use the language that best solves
>> the problem. This a pretty stupid example, but hell I shouldn't be
>> surprised.
>
> and whats wrong with python/perl, both are more portable than java,
> which has licence restrictions.
>
Wouldn't .NET/mono also be an option?
cc
Just using java as an example. Johnny wants to write a portable app, so
he should use a language that's portable, otherwise prepare for some
headaches.
The Ghost In The Machine
<scat...@hotmail.com>
wrote
on 17 Oct 2006 13:11:43 -0700
<1161115903.1...@m73g2000cwd.googlegroups.com>:
Comparative rather than positive; both C# and Java run on
both Windows and Linux, to some extent. It's the "some
extent" that makes life interesting; at least with Java
I know all of the API is there on both platforms (and
probably the SWT API as well, plus whatever third-party
.jars I throw at the problem). If one can live with a
slightly off GUI (though with SWT even that's not a problem)
Java's a very good choice for portability.
I'm not quite as sure with C#/.NET, although Mono
has implemented a significant fraction of Microsoft's
environment. No doubt anything written on Linux.NET
would run on Windows.NET, but the reverse might get
weird.
--
#191, ewi...@earthlink.net
Windows. Because it's not a question of if.
It's a question of when.
--
Posted via a free Usenet account from http://www.teranews.com
ericmatteson...@hotmail.com
Hadron Quark wrote:
> A little excercise in Linux advocacy here for you - I certainly hope to
> have a few things clarified as its all very, very confusing at the moment.
>
> Little Johnny, who has been a windows programmer for years, is familiar
> with gui windowing systems, C and C++. At a push he could be bothered to
> learn some Perl or whatever else. However, he doesn't want to do
> anything in Java.
>
> wordprocessor, bitmapped graphics display and audio.
>
> He wonders which APIs/Toolhits he should use, which Desktop Environments
> he should design it for. His brother told him Gnome sucked and that KDE
> was better. He is confused. He wants his app to run on all Linux systems
> the same.
>
> He has worked for years on a new rendering code path which speeds up 32
> bit colour masking by a factor of 8. He wishes to use this in his new
> app - but obviously doesnt want to hand out the algorithms source code
> in his app which he plans to sell.
>
> Discuss.
I am reccommending the traditional c language interface <X11/Xutil.h>
or whatever header file spelling is in the XWindows example program
called xwview03.c
xwview03.c is an example program that describes how to use and
TRANSLATE THE KEYBOARD yourself and deals with graphics PIXELS
that are first created in FOUR VIRTUAL BITPLANES. the plane mask
within each gc before each partial copy is used to control color.
The xwview03.c is a viewer to view plain old uncompressed paintbrush
*.bmp dib files.
It even has the algorithm to develop a font so characters can be
displayed
on a graphics only XWindows screen.
XWindows is NOT MICROSOFT WINDOWS.
In Xwindows each color is assigned to a seperate bit plane. bits within
a byte
are backwards but the picture is up side up.
In Microsoft Windows all colors are assigned to multibit pixels 4 bits
per
pixel with most significant pixel in each byte first but the picture as
a whole
is upside down under Microsoft.
It is not possible to copy a Windows program and rename the function
calls
and expect it to work under Linux.
XWindows uses different algorithms and displays bits in different
groups and
in different orders from Microsoft Windows.
The STAR WARS script that is linked to by this article has some links
on
it. The link to the xwview03.c is probably the best one for Johnny
because that
one is the one that supports color in XWindows.
Within xwview03.c you can hunt for keywords about xwindows and then
google search those individual keywords for more information. It is
very hard
to get documentation for Linux. Going through the StarWars script at
the link below
is the best way to get a link to an example in C that uses XWindows.
http://groups.google.com/group/alt.bill-gates.kind.benificent.loving.big-brother/msg/b750fb17cde7214e
Eric Matteson
ericmatteson2003novem...
spi...@freenet.co.uk
> Let's be fair when discussing the ginormousness of things:
> KDE <==> Gnome
> Qt <==> GTK
True, true.
The other issue is of course... gtk can be written in C or C++ (with the
gtkmm wrapper libraries). Qt is C++ only.
--
______________________________________________________________________________
| spi...@freenet.co.uk | |
|Andrew Halliwell BSc(hons)| "The day Microsoft makes something that doesn't |
| in | suck is probably the day they start making |
| Computer science | vacuum cleaners" - Ernst Jan Plugge |
------------------------------------------------------------------------------
Hadron Quark
> Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>> Let's be fair when discussing the ginormousness of things:
>
>> KDE <==> Gnome
>> Qt <==> GTK
>
> True, true.
> The other issue is of course... gtk can be written in C or C++ (with the
> gtkmm wrapper libraries). Qt is C++ only.
Just thought I'd pop back to this thread.
It's a minefield isn't it?
--
> No manual is ever necessary.
May I politely interject here: BULLSHIT. That's the biggest Apple lie of all!
-- Discussion in comp.os.linux.misc on the intuitiveness of interfaces
spi...@freenet.co.uk
>> Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>>> Let's be fair when discussing the ginormousness of things:
>>
>>> KDE <==> Gnome
>>> Qt <==> GTK
>>
>> True, true.
>> The other issue is of course... gtk can be written in C or C++ (with the
>> gtkmm wrapper libraries). Qt is C++ only.
> Just thought I'd pop back to this thread.
> It's a minefield isn't it?
No.
No it isn't. You choose which ever toolkit suits your particular needs.
Simple, though, not quite so simple as you are.
Remember, cross platorm programming is also an issue, and nothing microsoft
ever produced could do that. MSX was an attempt but MSX itself was a
platform.
--
______________________________________________________________________________
| spi...@freenet.co.uk | "I'm alive!!! I can touch! I can taste! |
|Andrew Halliwell BSc(hons)| I can SMELL!!! KRYTEN!!! Unpack Rachel and |
| in | get out the puncture repair kit!" |
| Computer Science | Arnold Judas Rimmer- Red Dwarf |
------------------------------------------------------------------------------
Hadron Quark
> Hadron Quark <qadro...@geemail.com> did eloquently scribble:
>> spi...@freenet.co.uk writes:
>
>>> Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>>>> Let's be fair when discussing the ginormousness of things:
>>>
>>>> KDE <==> Gnome
>>>> Qt <==> GTK
>>>
>>> True, true.
>>> The other issue is of course... gtk can be written in C or C++ (with the
>>> gtkmm wrapper libraries). Qt is C++ only.
>
>> Just thought I'd pop back to this thread.
>
>> It's a minefield isn't it?
>
> No.
> No it isn't. You choose which ever toolkit suits your particular
> needs.
Yes.
> Simple, though, not quite so simple as you are.
Define needs : or give me a blue print please. It isn't that
simple. Should I toss a coin? Which Window Manager should I specialise
in? Choice? Sure.
As for me being simple, I do not need to show off my degree in a .sig as
you do every day. Are you insecure?
> Remember, cross platorm programming is also an issue, and nothing microsoft
> ever produced could do that. MSX was an attempt but MSX itself was a
> platform.
Nothing Linux or Linus produced ever gave that either. What do you mean?
These toolkits are 3rd party. The can be used to develop on Windows too
- so to bring Windows into it shows you are either trolling or ignorant
of what a cross platform toolkit API and library collection really is.
Deciding which ones is a minefield.
--
You are a vile asshole, flatfish. : Peter Köhlmann, COLA.
Bob Hauck
<qadro...@geemail.com> wrote:
> Define needs : or give me a blue print please. It isn't that
> simple. Should I toss a coin?
You're the one writing the program. How can someone else define your
needs for you? If all else fails, by all means toss a coin.
> Which Window Manager should I specialise in? Choice? Sure.
You almost never need to care about that, regardless of which toolkit
you choose.
> These toolkits are 3rd party.
Except they come with all popular desktop distros and they are also
redistributable by you. This is no harder than having to include
VBRUN6.DLL in your pacakge.
JEDIDIAH
> spi...@freenet.co.uk writes:
>
>> Hadron Quark <qadro...@geemail.com> did eloquently scribble:
>>> spi...@freenet.co.uk writes:
>>
>>>> Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>>>>> Let's be fair when discussing the ginormousness of things:
>>>>
>>>>> KDE <==> Gnome
>>>>> Qt <==> GTK
>>>>
>>>> True, true.
>>>> The other issue is of course... gtk can be written in C or C++ (with the
>>>> gtkmm wrapper libraries). Qt is C++ only.
>>
>>> Just thought I'd pop back to this thread.
>>
>>> It's a minefield isn't it?
>>
>> No.
>> No it isn't. You choose which ever toolkit suits your particular
>> needs.
>
> Yes.
>
>> Simple, though, not quite so simple as you are.
>
> Define needs : or give me a blue print please. It isn't that
> simple. Should I toss a coin? Which Window Manager should I specialise
> in? Choice? Sure.
It's an irrelevant question.
>
> As for me being simple, I do not need to show off my degree in a .sig as
> you do every day. Are you insecure?
>
>> Remember, cross platorm programming is also an issue, and nothing microsoft
>> ever produced could do that. MSX was an attempt but MSX itself was a
>> platform.
>
> Nothing Linux or Linus produced ever gave that either. What do you mean?
That wasn't his thing. Although GNU has come remarkably close.
>
> These toolkits are 3rd party. The can be used to develop on Windows too
> - so to bring Windows into it shows you are either trolling or ignorant
> of what a cross platform toolkit API and library collection really is.
>
> Deciding which ones is a minefield.
Not really. It's no worse than dealing with the same
issues under WinDOS. Infact, you could use the EXACT SAME
strategies you would use as a (genuine) Win32 programmer to
address the same "problem" under Linux.
--
Metallica is not worth the ruination of someone |||
who has pirated their music / | \
Hadron Quark
> On Wed, 18 Oct 2006 18:02:49 +0200, Hadron Quark
> <qadro...@geemail.com> wrote:
>
>
>> Define needs : or give me a blue print please. It isn't that
>> simple. Should I toss a coin?
>
> You're the one writing the program. How can someone else define your
> needs for you? If all else fails, by all means toss a coin.
No. Define "needs". Not my needs. What does he mean by "needs". "needs"
might mean "play a tune" - but which sound subsystem? maybe "draw a
circle" : which toolkit.
Anyway, I think we've done this to death - and as I suspected the most
prevalent answer is "choice is a good thing". I dont think it is - it
leads to disjointed, non standard apps.
>
>> Which Window Manager should I specialise in? Choice? Sure.
>
> You almost never need to care about that, regardless of which toolkit
> you choose.
This way of thinking is evident of the way so many Linux GUI apps
suck. It is improtant to know because otherwise your app will be alien
on another desktop. Sure it will "work" but it needs loads of supporting
frameworks. Suddenly you have TWO library frameworks installed. The GUI
guidelines are different for each and every WM.
I cant believe some of you are denying that this is a potential
minefield.
>
>
>> These toolkits are 3rd party.
>
> Except they come with all popular desktop distros and they are also
> redistributable by you. This is no harder than having to include
> VBRUN6.DLL in your pacakge.
Err, I know. I was pointing out that they are not "Linux".
--
lp1 on fire
-- One of the more obfuscated kernel messages
cc
How is it a minefield? You asked for a portable program to be written
using tools that aren't portable. Amazingly, that isn't so easy.
Little Johnny wants to build a log cabin using a screw driver. He can't
be bothered to learn how to use a hammer. In a pinch he will learn how
to use a hand saw.
Hadron Quark
> Hadron Quark wrote:
>> spi...@freenet.co.uk writes:
>>
>> > Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>> >> Let's be fair when discussing the ginormousness of things:
>> >
>> >> KDE <==> Gnome
>> >> Qt <==> GTK
>> >
>> > True, true.
>> > The other issue is of course... gtk can be written in C or C++ (with the
>> > gtkmm wrapper libraries). Qt is C++ only.
>>
>> Just thought I'd pop back to this thread.
>>
>> It's a minefield isn't it?
>>
>> --
>> > No manual is ever necessary.
>> May I politely interject here: BULLSHIT. That's the biggest Apple lie of all!
>> -- Discussion in comp.os.linux.misc on the intuitiveness of interfaces
>
> How is it a minefield? You asked for a portable program to be written
> using tools that aren't portable. Amazingly, that isn't so easy.
No I didn't. I said he didnt want to make his app "desktop choice"
specific. Someone else started huffing & puffing about cross platform.
Look guys : if you dont know about windowing APIs, cross platform APIs,
widget toolkits, different WMs etc, C/C++ differences then please dont
offer an opinion. It's almost too painful to hear you totally
misunderstanding whats involved.
>
> Little Johnny wants to build a log cabin using a screw driver. He can't
> be bothered to learn how to use a hammer. In a pinch he will learn how
> to use a hand saw.
>
--
fornication, n.:
Term used by people who don't have anybody to screw with.
The Ghost In The Machine
<87zmbta...@geemail.com>:
> spi...@freenet.co.uk writes:
>
>> Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>>> Let's be fair when discussing the ginormousness of things:
>>
>>> KDE <==> Gnome
>>> Qt <==> GTK
>>
>> True, true.
>> The other issue is of course... gtk can be written in C or C++ (with the
>> gtkmm wrapper libraries). Qt is C++ only.
>
> Just thought I'd pop back to this thread.
>
> It's a minefield isn't it?
>
Yes it is. If you're not careful your code might actually
be ... *gasp* ... portable to other, non-Linux platforms.
:-)
--
#191, ewi...@earthlink.net
Windows. Multi-platform(1), multi-tasking(1), multi-user(1).
(1) if one defines "multi" as "exactly one".
Hadron Quark
> In comp.os.linux.advocacy, Hadron Quark
> <qadro...@geemail.com>
> wrote
> on Wed, 18 Oct 2006 17:19:20 +0200
> <87zmbta...@geemail.com>:
>> spi...@freenet.co.uk writes:
>>
>>> Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>>>> Let's be fair when discussing the ginormousness of things:
>>>
>>>> KDE <==> Gnome
>>>> Qt <==> GTK
>>>
>>> True, true.
>>> The other issue is of course... gtk can be written in C or C++ (with the
>>> gtkmm wrapper libraries). Qt is C++ only.
>>
>> Just thought I'd pop back to this thread.
>>
>> It's a minefield isn't it?
>>
>
> Yes it is. If you're not careful your code might actually
> be ... *gasp* ... portable to other, non-Linux platforms.
>
> :-)
I know. But thats not much good if the app is, say, a graphical front
end to the Linux hardware subsystem is it?
FWIW, I have written major apps and build crossplatform APIs for Win32 &
OS/2 PM/GPI so do know a little about this subject.
And I am very wary of toolkits whose developers have a limited income
and no guarentee of being there in a few years.
Even the fact the Gnome is C compared to KDEs C++ raises a bunch of
interesting application design issues.
>
> --
> #191, ewi...@earthlink.net
> Windows. Multi-platform(1), multi-tasking(1), multi-user(1).
> (1) if one defines "multi" as "exactly one".
--
Q: Why shouldn't I simply delete the stuff I never use, it's just taking up
space?
A: This question is in the category of Famous Last Words..
-- From the Frequently Unasked Questions
spi...@freenet.co.uk
>> On Wed, 18 Oct 2006 18:02:49 +0200, Hadron Quark
>> <qadro...@geemail.com> wrote:
>>
>>
>>> Define needs : or give me a blue print please. It isn't that
>>> simple. Should I toss a coin?
>>
>> You're the one writing the program. How can someone else define your
>> needs for you? If all else fails, by all means toss a coin.
> No. Define "needs". Not my needs. What does he mean by "needs". "needs"
> might mean "play a tune" - but which sound subsystem? maybe "draw a
> circle" : which toolkit.
Needs: Language, size, efficiency, function
Those terms simple enough for you?
Hint: You don't need to program for the full KDE/Qt if all you need is a
combobox widget and a few menus.
>>> Which Window Manager should I specialise in? Choice? Sure.
>>
>> You almost never need to care about that, regardless of which toolkit
>> you choose.
> This way of thinking is evident of the way so many Linux GUI apps
> suck.
Bull.
doesn't affect the actual function of the program though does it.
Doesn't affect the feel either in most cases. And the window manager only
handles the border and window bar look/feel, it doesn't affect the actual
application itself.
--
| |What to do if you find yourself stuck in a crack|
| spi...@freenet.co.uk |in the ground beneath a giant boulder, which you|
| |can't move, with no hope of rescue. |
|Andrew Halliwell BSc(hons)|Consider how lucky you are that life has been |
| in |good to you so far... |
| Computer Science | -The BOOK, Hitch-hiker's guide to the galaxy.|
spi...@freenet.co.uk
> widget toolkits, different WMs etc, C/C++ differences then please dont
> offer an opinion. It's almost too painful to hear you totally
> misunderstanding whats involved.
That's rich.
You came out with THE most vague and undefined objectives you possible could
just so you could attack everyone who replied to you.
The only person who can decide what he needs from his GUI toolkit is "little
johnny" himself.
Poor sod, being named after an undersized condom.
The Ghost In The Machine
<87ac3tx...@geemail.com>:
> "cc" <scat...@hotmail.com> writes:
>
>> Hadron Quark wrote:
>>> spi...@freenet.co.uk writes:
>>>
>>> > Bob Hauck <postm...@localhost.localdomain> did eloquently scribble:
>>> >> Let's be fair when discussing the ginormousness of things:
>>> >
>>> >> KDE <==> Gnome
>>> >> Qt <==> GTK
>>> >
>>> > True, true.
>>> > The other issue is of course... gtk can be written in C or C++ (with the
>>> > gtkmm wrapper libraries). Qt is C++ only.
>>>
>>> Just thought I'd pop back to this thread.
>>>
>>> It's a minefield isn't it?
>>>
>>> --
>>> > No manual is ever necessary.
>>> May I politely interject here: BULLSHIT. That's the biggest Apple lie of all!
>>> -- Discussion in comp.os.linux.misc on the intuitiveness of interfaces
>>
>> How is it a minefield? You asked for a portable program to be written
>> using tools that aren't portable. Amazingly, that isn't so easy.
>
> No I didn't. I said he didnt want to make his app "desktop choice"
> specific. Someone else started huffing & puffing about cross platform.
>
> Look guys : if you dont know about windowing APIs, cross platform APIs,
> widget toolkits, different WMs etc, C/C++ differences then please dont
> offer an opinion. It's almost too painful to hear you totally
> misunderstanding whats involved.
OK, dumb question. What exactly is the problem here?
Is it:
[1] I have/want to develop a Gnome-based app that I want
to run on a KDE desktop, or vice versa.
[2] I want to display one machine's desktop on another
machine's display.
[3] I want to run an app on one machine and have its GUI
display on another.
[4] I have an app that must run Gnome on Gnome-based desktops,
and KDE on KDE-based desktops, Windows on Windows-based
desktops, and CLI on CLI-based equipment.
[5] I have an app that runs on one computer and displays in accordance
with the desktop type (KDE/Qt, Gnome/Gtk, raw X, Windows, CLI) on
a second computer.
[6] none of the above?
[1] is routine; just install the other system (the
two coexist readily on Linux, and one can use WinE if
Windows is involved). [2] is doable for Gnome desktops;
I've not had success with KDE but haven't thorougly
researched the issue. [3] is handled at the X level or
with tools such as vncviewer or rdesktop, and the GUIs
might clash, but for most of us that's not a big issue.
[4] will probably require two or more versions of the app
(though the differences might be minimizable with good
development techniques); [5] is even trickier.
[little Johnny snipped for brevity :-) ]
--
#191, ewi...@earthlink.net
Linux makes one use one's mind.
Windows just messes with one's head.
The Ghost In The Machine
<87r6x5e...@geemail.com>:
> Bob Hauck <postm...@localhost.localdomain> writes:
>
>> On Wed, 18 Oct 2006 18:02:49 +0200, Hadron Quark
>> <qadro...@geemail.com> wrote:
>>
>>
>>> Define needs : or give me a blue print please. It isn't that
>>> simple. Should I toss a coin?
>>
>> You're the one writing the program. How can someone else define your
>> needs for you? If all else fails, by all means toss a coin.
>
> No. Define "needs". Not my needs. What does he mean by "needs". "needs"
> might mean "play a tune" - but which sound subsystem? maybe "draw a
> circle" : which toolkit.
I see no needs of any sort here. Perhaps a philosophical
thought or two is in order; the only need, after all, is to
survive, and even that might not be a true need, especially
if one is trying to save others or has been charged through
the legal process with a crime so heinous the death penalty
is recommended by 12 of one's peers (here in the US).
However, given that need, one can have dependencies --
e.g., to survive, one must have food (unless one puts in
a time-dependency of about 40 days), water, air, etc.
Does one need Windows? Linux? Depends on one's
objectives, but clearly without some software the
modern x86-based computer is an inert lump, even if
one assumes the BIOS (which is base-level software) is
already installed, in which case one could get an inert
lump stating
MISSING OPERATING SYSTEM
or some such.
(And without electrical power, monitor, and appropriate cabling
one won't even get that.)
One can also use the comparative form. Given choice,
which selection will be more efficient, faster, use less
memory, get the job done more effectively, etc.? A lot of
businesses have to struggle with this sort of comparison,
when upgrading.
>
> Anyway, I think we've done this to death - and as I suspected the most
> prevalent answer is "choice is a good thing". I dont think it is - it
> leads to disjointed, non standard apps.
The problem is inherently multilayer, unless the app can
directly talk to the hardware; for portability and security
reasons, few apps do. Also, it shrinks down the app to push
certain problems (e.g., deciding where data blocks need to be
stored and then having the disk store them) to "somewhere else".
And in any event there's choice in Windows, too. There are many
third-party apps.
>
>>
>>> Which Window Manager should I specialise in? Choice? Sure.
>>
>> You almost never need to care about that, regardless of which toolkit
>> you choose.
>
> This way of thinking is evident of the way so many Linux GUI apps
> suck. It is improtant to know because otherwise your app will be alien
> on another desktop. Sure it will "work" but it needs loads of supporting
> frameworks. Suddenly you have TWO library frameworks installed. The GUI
> guidelines are different for each and every WM.
>
> I cant believe some of you are denying that this is a potential
> minefield.
Not a potential minefield, either. If I start up Konqueror
on my Gnome box, a good chunk of KDE starts up with it.
Depending on configuration, this may disable sound as well,
as aRts and ALSA do not like each other for some reason,
at least, such is my rememberance.
Kaboom.
This doesn't mean we shouldn't try, of course. Standards help;
they provide an underlayer which everyone can depend on. These
standards can be explicit or de facto. Windows is a de facto
standard and can generally be relied upon -- maybe.
>
>>
>>
>>> These toolkits are 3rd party.
>>
>> Except they come with all popular desktop distros and they are also
>> redistributable by you. This is no harder than having to include
>> VBRUN6.DLL in your pacakge.
>
> Err, I know. I was pointing out that they are not "Linux".
>
Linux is all third party. Except for the kernel proper and some
of the distro support scripts, everything is from somewhere else.
I don't see this as a problem, but I'm not sure how strong an
argument it is either direction.
--
#191, ewi...@earthlink.net
fortune: not found
Hadron Quark
>
> OK, dumb question. What exactly is the problem here?
There is no problem : I asked posters to discuss how a developer
decides which tools and "choice process" a developer would use to
determine how best to develop a Linux GUI app. Ideally it would be WM
independent but that's not really possible if you want to make use of
certain libraries such as GTK or QT. The choice of one of these then
influences the language you use.
I never said it had to be cross platform.
The zealots have tried to pull the thread down like a tiger after a baby
gazelle.
The Ghost In The Machine
<87zmbtt...@geemail.com>:
> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> writes:
>
>>
>> OK, dumb question. What exactly is the problem here?
>
> There is no problem :
Oh yes there is. The Linux desktop can get very
disjointed-looking. This is not a major problem but it
*is* a problem, to some.
Internally, there's a large but easily jumpable chasm
from the Qt side to the Gtk side; the two are different
environments but both sit on X. Motif is off in the
corner, Java, C#, and Squeak are in their own little
worlds.
> I asked posters to discuss how a developer
> decides which tools and "choice process" a developer would use to
> determine how best to develop a Linux GUI app.
The first question: which GUI/environment? There are at least six,
which I list here in no particular order.
[1] MIT Athena. This is deprecated for obvious reasons,
although Xaw3d at least makes it look a bit nicer.
[2] Motif or Lesstif.
[3] Gnome/Gtk
[4] Qt/KDE
[5] Custom. Basically, "roll your own"; this is probably
not something one would do unless one's in one's own
little world (e.g., UT2004 obviously rolled their own
widget set in their game, and didn't concern themselves
with such things as cut and paste).
[6] Python. Blender, in particular, uses Python, AFAICT.
[7] Tcl/Tk or Perl/Tk. Tk is the actual GUI, with things such
as the usual buttons, text widgets, and canvasses.
It's showing its age (it was originally written in C)
but is very flexible.
[8] ncurses in a terminal emulator. For certain
applications (e.g. SLRN) this makes a lot of sense.
For certain other applications this makes no sense
at all.
If one wishes I can add Java/Swing as well, since it looks
a bit different. I don't know much about MonoDevelop and
.NET, though I have gotten it to work; one might count
that as #10. If one uses Gtk#, however, the look and feel
will be very similar to Gtk -- ideally it would be almost
identical but there are probably issues with respect to
event handling.
There's a few others which have since vanished, or might
be of some interest -- Interviews is the only one I
can think of. It was out of Stanford and was C++-based.
It mutated to Fresco at one point and that's the last I've
heard of it.
Another one which was touted was Berlin; this one would
bypass X.
Yet another is Squeak's. I frankly don't know what to
call it, as Squeak, like UT2004, is generally in its own
little world anyway.
No doubt BeOS had something. I've no idea what now.
> Ideally it would be WM
> independent but that's not really possible if you want to make use of
> certain libraries such as GTK or QT.
I doubt either Gtk or Qt care all that much. The WM in
any event is accessed through X library calls such as
XSetWMProperties(), when all is said and done. Want a
certain window size? Set up XMHints. That's the level of
involvement; all window managers are required to honor most
of the settings there.
There might be some subtleties such as whether windows will
"scrape" against each other or be programmatically positionable
(which is generally considered slightly naughty anyway), but
otherwise one could use an application with the twm window manager,
as easily as with metacity.
The main issue there is that the user gets to position
everything in twm, since twm is a little brain-dead.
Otherwise, this smells like a red herring.
> The choice of one of these then
> influences the language you use.
And the tools. I doubt kdevelop would work all that well with
Gnome, for example -- though I've not tried it.
>
> I never said it had to be cross platform.
No, but most good apps should be. There are at least five
platforms in common use that support GUIs of some sort.
- Windows.
- Linux.
- MacOSX.
- FreeBSD.
- All other Unices.
Granted, one could quibble about the last since there's a fair number of
difference between Solaris and HP/UX, for example.
>
> The zealots have tried to pull the thread down like a tiger after a baby
> gazelle.
Oh, the horror.
--
#191, ewi...@earthlink.net
Useless C++ Programming Idea #10239993:
char * f(char *p) {char *q = malloc(strlen(p)); strcpy(q,p); return q; }
Bob Hauck
<qadro...@geemail.com> wrote:
> Bob Hauck <postm...@localhost.localdomain> writes:
>
>> On Wed, 18 Oct 2006 18:02:49 +0200, Hadron Quark
>> <qadro...@geemail.com> wrote:
>>> Define needs : or give me a blue print please. It isn't that
>>> simple. Should I toss a coin?
>>
>> You're the one writing the program. How can someone else define your
>> needs for you? If all else fails, by all means toss a coin.
>
> No. Define "needs". Not my needs. What does he mean by "needs". "needs"
> might mean "play a tune" - but which sound subsystem?
Use ALSA unless there's some reason to do otherwise. Modern distros
have it set up so that artsd or esd or whatever will play nicely with
apps that access the sound directly.
Except on your box of course, where everything is broken.
> maybe "draw a circle" : which toolkit.
Qt or GTK. Pick whichever one you like.
> Anyway, I think we've done this to death - and as I suspected the most
> prevalent answer is "choice is a good thing". I dont think it is - it
> leads to disjointed, non standard apps.
You seem to have this idea that someone, somewhere, can seize control
and push things along toward uniformity if you or a gang of you's just
whine enough. There should be only a few distros, there should be only
one primary UI toolkit, there should be only a few ways to do things.
Well, sorry, but that is a fundamentally misguided notion. It is just
never going to happen no matter what you wish for. Linux is not a
unified product from a single vendor.
That's kind of the point. You don't have to like it, or agree with it,
but it *is*.
>>> Which Window Manager should I specialise in? Choice? Sure.
>>
>> You almost never need to care about that, regardless of which toolkit
>> you choose.
>
> This way of thinking is evident of the way so many Linux GUI apps
> suck. It is improtant to know because otherwise your app will be alien
> on another desktop.
That's not a function of the window manager, it is a function of the
toolkit used to write the "desktop environment". The window manager
isn't directly relevant.
I think you're making a bigger deal of this than real users do. But if
you are interested in actual solutions you might want to look at what
freedesktop.org is doing with toolkit interoperability standards.
That is the realistic way to attack this problem, by dealing with how
things are, as opposed to whining that there is too much choice.
> Sure it will "work" but it needs loads of supporting
> frameworks. Suddenly you have TWO library frameworks installed. The
> GUI guidelines are different for each and every WM.
Almost everybody has both major frameworks already in place, so there is
nothing sudden or unexpected about it. Everybody who has used Linux for
any length of time is aware of this issue, just as Mac and Windows users
learn the foibles of their systems. Almost no users will avoid your
program simply because it uses one toolkit or the other.
And once more, the GUI guidelines aren't defined by the window manager,
but by the toolkit. You are confused about the role the WM plays.
> I cant believe some of you are denying that this is a potential
> minefield.
If you want to get in on a new market and write for Linux, you'll just
have to deal with that. Or you can sit on the sidelines and bitch.
>>> These toolkits are 3rd party.
>>
>> Except they come with all popular desktop distros and they are also
>> redistributable by you. This is no harder than having to include
>> VBRUN6.DLL in your pacakge.
>
> Err, I know.
So what are you whining about then? Pick one and use it.
> I was pointing out that they are not "Linux".
Whatever that is supposed to mean.
GTK and Qt were both initially developed for "Linux", and they are
ubiquitous on "Linux" as distributed by the popular distros. From an
application developer's perspective, that makes them "part of Linux", in
that you can assume they are installed.
Hadron Quark
> In comp.os.linux.advocacy, Hadron Quark
> <qadro...@geemail.com>
> wrote
> on Wed, 18 Oct 2006 23:48:24 +0200
> <87zmbtt...@geemail.com>:
>> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> writes:
>>
>>>
>>> OK, dumb question. What exactly is the problem here?
>>
>> There is no problem :
>
> Oh yes there is. The Linux desktop can get very
> disjointed-looking. This is not a major problem but it
> *is* a problem, to some.
Good you agree. BTW when I said "no problem" I meant in terms of my
simple request.
Your reply is appreciated : it does hilite the minefield out there for
the unsuspecting developer.
>
> Internally, there's a large but easily jumpable chasm
> from the Qt side to the Gtk side; the two are different
> environments but both sit on X. Motif is off in the
Doesnt matter : they are incompatible APIs. They use different
programming languages.
> corner, Java, C#, and Squeak are in their own little
> worlds.
>
>> I asked posters to discuss how a developer
>> decides which tools and "choice process" a developer would use to
>> determine how best to develop a Linux GUI app.
>
> The first question: which GUI/environment? There are at least six,
> which I list here in no particular order.
Correct.
>
> [1] MIT Athena. This is deprecated for obvious reasons,
> although Xaw3d at least makes it look a bit nicer.
>
> [2] Motif or Lesstif.
>
> [3] Gnome/Gtk
>
> [4] Qt/KDE
>
> [5] Custom. Basically, "roll your own"; this is probably
> not something one would do unless one's in one's own
> little world (e.g., UT2004 obviously rolled their own
> widget set in their game, and didn't concern themselves
> with such things as cut and paste).
Well, like all bit mapped games. But their underlying unreal engine
would have provided them basic sprite & texture manipulation and a few
default fonts etc I would think ....
The WM is also accessed though GTK/QT specific API function calls.
>
> There might be some subtleties such as whether windows will
> "scrape" against each other or be programmatically positionable
> (which is generally considered slightly naughty anyway), but
> otherwise one could use an application with the twm window manager,
> as easily as with metacity.
>
> The main issue there is that the user gets to position
> everything in twm, since twm is a little brain-dead.
> Otherwise, this smells like a red herring.
>
>> The choice of one of these then
>> influences the language you use.
>
> And the tools. I doubt kdevelop would work all that well with
> Gnome, for example -- though I've not tried it.
>
>>
>> I never said it had to be cross platform.
>
> No, but most good apps should be. There are at least five
Depends what the app is for. As I said before, I dont think there would
be much call for a Linux HW analyser under Windows .....
> platforms in common use that support GUIs of some sort.
>
> - Windows.
> - Linux.
> - MacOSX.
> - FreeBSD.
> - All other Unices.
>
> Granted, one could quibble about the last since there's a fair number of
> difference between Solaris and HP/UX, for example.
>
>>
>> The zealots have tried to pull the thread down like a tiger after a baby
>> gazelle.
>
> Oh, the horror.
>
> --
> #191, ewi...@earthlink.net
> Useless C++ Programming Idea #10239993:
> char * f(char *p) {char *q = malloc(strlen(p)); strcpy(q,p); return q; }
--
This end up.
Hadron Quark
> On Wed, 18 Oct 2006 19:17:46 +0200, Hadron Quark
> <qadro...@geemail.com> wrote:
>
>> Bob Hauck <postm...@localhost.localdomain> writes:
>>
>>> On Wed, 18 Oct 2006 18:02:49 +0200, Hadron Quark
>>> <qadro...@geemail.com> wrote:
>
>>>> Define needs : or give me a blue print please. It isn't that
>>>> simple. Should I toss a coin?
>>>
>>> You're the one writing the program. How can someone else define your
>>> needs for you? If all else fails, by all means toss a coin.
>>
>> No. Define "needs". Not my needs. What does he mean by "needs". "needs"
>> might mean "play a tune" - but which sound subsystem?
>
> Use ALSA unless there's some reason to do otherwise. Modern distros
> have it set up so that artsd or esd or whatever will play nicely with
> apps that access the sound directly.
"use ALSA" .. another person with ZERO clue about systems programming.
>
> Except on your box of course, where everything is broken.
>
>
>> maybe "draw a circle" : which toolkit.
>
> Qt or GTK. Pick whichever one you like.
Oh my god. You really think its that simple? Jesus. No wonder so many
home brew linux apps look like shit.
>
>
>> Anyway, I think we've done this to death - and as I suspected the most
>> prevalent answer is "choice is a good thing". I dont think it is - it
>> leads to disjointed, non standard apps.
>
> You seem to have this idea that someone, somewhere, can seize control
> and push things along toward uniformity if you or a gang of you's just
Someone should. Its called UI standards. Standards work for people.
*snip more bullshit about choice*
cc
You go with whatever libraries the customer wants? Or in the case of no
customer, whatever you want? So cross platform is not desired, sorry I
screwed that up, but I don't see how that changes anything. The "choice
process" is no different from developing a Windows GUI app. Customers
have specific requirements, and you develop to those requirements.
You're pretending like these problems don't exist for Windows or other
OSes. The "choice process" is the same regardless of OS, WM, or
anything else. You can't have a "choice process" if you've already
limited yourself to C/C++ at the get go.
Hadron Quark
> Hadron Quark wrote:
>> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> writes:
>>
>> >
>> > OK, dumb question. What exactly is the problem here?
>>
>> There is no problem : I asked posters to discuss how a developer
>> decides which tools and "choice process" a developer would use to
>> determine how best to develop a Linux GUI app. Ideally it would be WM
>> independent but that's not really possible if you want to make use of
>> certain libraries such as GTK or QT. The choice of one of these then
>> influences the language you use.
>>
>> I never said it had to be cross platform.
>>
>> The zealots have tried to pull the thread down like a tiger after a baby
>> gazelle.
>
>
> You go with whatever libraries the customer wants? Or in the case of no
> customer, whatever you want? So cross platform is not desired, sorry I
> screwed that up, but I don't see how that changes anything. The "choice
> process" is no different from developing a Windows GUI app. Customers
It is SO different it is not funny.
> have specific requirements, and you develop to those requirements.
Johnny wants to create his own market. There are no customer specs
YET. There might be later down the road - lets hope he picks the right
WM to integrate with then eh? Otherwise he's fucked.
> You're pretending like these problems don't exist for Windows or other
They dont. Not to the same extent.
> OSes. The "choice process" is the same regardless of OS, WM, or
> anything else. You can't have a "choice process" if you've already
> limited yourself to C/C++ at the get go.
>
This is totally bogus.
--
Do not dry clean.
cc
Why though? Shouldn't the first choice after deciding what you're going
to do, be what language to use? So you pick the language that works
best right?
Hadron Quark
if you are only comfortable with one language maybe. I'm familiar with
both c and c++.
The first thing to decide is which APIs you need to get the "job done"* and
then see which bindings are available for that API.
* : and "job done" means a lot of things. Functional completeness,
compatability with clients on site work, future safe knowledge
investment etc etc. Its not a trivial choice at all.
--
<posix> this guy _is_ crazy
<stargazer> posix: from the looks of Enlightenment he's on LSD
<posix> LSD is nothing compared to what this guy's on..
-- Seen on #Unix
Gregory Shearman
> Johnny wants to create his own market. There are no customer specs
> YET. There might be later down the road - lets hope he picks the right
> WM to integrate with then eh? Otherwise he's fucked.
So, Johnny wants to sell proprietary software on an open source machine? Or
Does he want to sell open source software on a predominantly FREE software
platform?
I suppose "Johnny" is used to the Windows software development model, eh?
--
Regards,
Gregory.
"Ding-a-ding-dang,My Dang-a-long ling-long"
Bob Hauck
<qadro...@geemail.com> wrote:
> Bob Hauck <postm...@localhost.localdomain> writes:
>> Use ALSA unless there's some reason to do otherwise.
> "use ALSA" .. another person with ZERO clue about systems programming.
Another asshole with an agenda.
Hadron Quark
> On Thu, 19 Oct 2006 01:27:01 +0200, Hadron Quark
> <qadro...@geemail.com> wrote:
>
>> Bob Hauck <postm...@localhost.localdomain> writes:
>
>>> Use ALSA unless there's some reason to do otherwise.
>
>> "use ALSA" .. another person with ZERO clue about systems programming.
>
> Another asshole with an agenda.
Oh sorry, I didn't realise you had an agenda too.
You guys crack me up : all wind & water and little clue.
"Use ALSA" - lol. Talk about missing the point about all this.
--
Less is more or less more
-- Y_Plentyn on #LinuxGER
The Ghost In The Machine
<87ods9f...@geemail.com>:
> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> writes:
>
>> In comp.os.linux.advocacy, Hadron Quark
>> <qadro...@geemail.com>
>> wrote
>> on Wed, 18 Oct 2006 23:48:24 +0200
>> <87zmbtt...@geemail.com>:
>>> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> writes:
>>>
>>>>
>>>> OK, dumb question. What exactly is the problem here?
>>>
>>> There is no problem :
>>
>> Oh yes there is. The Linux desktop can get very
>> disjointed-looking. This is not a major problem but it
>> *is* a problem, to some.
>
> Good you agree. BTW when I said "no problem" I meant in terms of my
> simple request.
Your request is *not* simple. Of course, any development
project worth its salt is going to be non-simple anyway,
but it's clear that there are a lot of hidden assumptions
here. I'm a software engineer; it's my job to ferret them
out, and, like the proverbial general surveying a potential
battle, no plan survives first contact with the enemy. :-)
>
> Your reply is appreciated : it does hilite the minefield out there for
> the unsuspecting developer.
Minefields are always out there. If it's not a bad
spec by marketing, it's a dumb assumption by management.
If it's not a dumb assumption by management it's a coding
failure inadvertantly introduced by the engineer(s) (and
hopefully detected by QA later). If it's not a coding
failure it's a setup/communications problem as QA tries
to test the product. If it's not a setup/communications
problem in QA it's something from Customer Service who
discovered a completely hitherto unknown use of the product
that *no* one thought of during development, testing,
and distribution.
Get used to it. :-)
>
>>
>> Internally, there's a large but easily jumpable chasm
>> from the Qt side to the Gtk side; the two are different
>> environments but both sit on X. Motif is off in the
>
> Doesnt matter : they are incompatible APIs. They use different
> programming languages.
I don't know how "incompatible" they are. They appear to
work side-by-side easily enough, although they don't really
talk to each other; they talk through X.
>
>> corner, Java, C#, and Squeak are in their own little
>> worlds.
>>
>>> I asked posters to discuss how a developer
>>> decides which tools and "choice process" a developer would use to
>>> determine how best to develop a Linux GUI app.
>>
>> The first question: which GUI/environment? There are at least six,
>> which I list here in no particular order.
>
> Correct.
>
>>
>> [1] MIT Athena. This is deprecated for obvious reasons,
>> although Xaw3d at least makes it look a bit nicer.
>>
>> [2] Motif or Lesstif.
>>
>> [3] Gnome/Gtk
>>
>> [4] Qt/KDE
>>
>> [5] Custom. Basically, "roll your own"; this is probably
>> not something one would do unless one's in one's own
>> little world (e.g., UT2004 obviously rolled their own
>> widget set in their game, and didn't concern themselves
>> with such things as cut and paste).
>
> Well, like all bit mapped games.
Actually, QT2004 is a GL engine. Same issue, though.
> But their underlying unreal engine
> would have provided them basic sprite & texture manipulation
> and a few default fonts etc I would think ....
And this is relevant to the problem precisely why? I think
you're right but it's clear that they indeed rolled their own;
they wanted a certain effect.
And these are ... ?
If you're thinking of such things as XMoveWindow(), XResizeWindow(),
etc., these are *intercepted* by the WM (converted into events by
the X server, so that the WM can process them). WMs worth their
salt will process them. WMs who don't bother will ignore them, and
I think the window is left as is though I'd have to experiment.
>
>>
>> There might be some subtleties such as whether windows will
>> "scrape" against each other or be programmatically positionable
>> (which is generally considered slightly naughty anyway), but
>> otherwise one could use an application with the twm window manager,
>> as easily as with metacity.
>>
>> The main issue there is that the user gets to position
>> everything in twm, since twm is a little brain-dead.
>> Otherwise, this smells like a red herring.
>>
>>> The choice of one of these then
>>> influences the language you use.
>>
>> And the tools. I doubt kdevelop would work all that well with
>> Gnome, for example -- though I've not tried it.
>>
>>>
>>> I never said it had to be cross platform.
>>
>> No, but most good apps should be. There are at least five
>
> Depends what the app is for. As I said before, I dont think there would
> be much call for a Linux HW analyser under Windows .....
Why not? I could see a number of scenarios, most of
them having to do with data acquisition/scientific work,
where an app might run under both Linux and Windows.
(It would have to have differences, of course; the device
will probably have a driver and in Linux one would talk to
something in /dev, whereas Windows does something entirely
different. The driver itself would be a module in Linux;
I have no clue what Windows would need in that area.)
>
>> platforms in common use that support GUIs of some sort.
>>
>> - Windows.
>> - Linux.
>> - MacOSX.
>> - FreeBSD.
>> - All other Unices.
>>
>> Granted, one could quibble about the last since there's a fair number of
>> difference between Solaris and HP/UX, for example.
>>
>>>
>>> The zealots have tried to pull the thread down like a tiger after a baby
>>> gazelle.
>>
>> Oh, the horror.
[.sigsnip]
--
#191, ewi...@earthlink.net
Useless C++ Programming Idea #889123:
std::vector<...> v; for(int i = 0; i < v.size(); i++) v.erase(v.begin() + i);
The Ghost In The Machine
<87k62xf...@geemail.com>:
> Bob Hauck <postm...@localhost.localdomain> writes:
>
>> On Wed, 18 Oct 2006 19:17:46 +0200, Hadron Quark
>> <qadro...@geemail.com> wrote:
>>
>>> Bob Hauck <postm...@localhost.localdomain> writes:
>>>
>>>> On Wed, 18 Oct 2006 18:02:49 +0200, Hadron Quark
>>>> <qadro...@geemail.com> wrote:
>>
>>>>> Define needs : or give me a blue print please. It isn't that
>>>>> simple. Should I toss a coin?
>>>>
>>>> You're the one writing the program. How can someone else define your
>>>> needs for you? If all else fails, by all means toss a coin.
>>>
>>> No. Define "needs". Not my needs. What does he mean by "needs". "needs"
>>> might mean "play a tune" - but which sound subsystem?
>>
>> Use ALSA unless there's some reason to do otherwise. Modern distros
>> have it set up so that artsd or esd or whatever will play nicely with
>> apps that access the sound directly.
>
> "use ALSA" .. another person with ZERO clue about systems programming.
I'd have to look but I think SDL runs on both Windows
and Linux. That might be acceptable; if not, one simply
abstracts the problem to a system-dependent module. SDL
for its part has the drawback that it wants to take over
the entire screen.
>
>>
>> Except on your box of course, where everything is broken.
>>
>>
>>> maybe "draw a circle" : which toolkit.
>>
>> Qt or GTK. Pick whichever one you like.
>
> Oh my god. You really think its that simple? Jesus. No wonder so many
> home brew linux apps look like shit.
It's worse than that. Poor design at this layer will cause
major headaches later. One ideally would abstract the problem away.
Gtk in particular has a Gdk sublayer, and also a Cairo sublayer;
Cairo not only allows for subpixel rendering but also allows for
SVG, PDF, and bitmap generation.
However, one might still want to abstract away the
widgeting subproblem so as to substitute something else
later, such as something within Qt, raw X, or Win32.
>
>>
>>
>>> Anyway, I think we've done this to death - and as I suspected the most
>>> prevalent answer is "choice is a good thing". I dont think it is - it
>>> leads to disjointed, non standard apps.
>>
>> You seem to have this idea that someone, somewhere, can seize control
>> and push things along toward uniformity if you or a gang of you's just
>
> Someone should. Its called UI standards. Standards work for people.
And these are defined precisely where?
I could probably find the KDE and Gnome standards, since
those are specific to the KDE and Gnome environments.
ICCCM has some standards for interprocess communication
on an X server (and yes, that works cross KDE and Gnome,
though there are some issues if one is using things other
than the standard stuff, presumably). Microsoft might
have a set of specifications for applications to follow.
>
> *snip more bullshit about choice*
The Ghost In The Machine
<87ac3tx...@geemail.com>:
> "cc" <scat...@hotmail.com> writes:
>
>> Hadron Quark wrote:
>>> "cc" <scat...@hotmail.com> writes:
>>>
>>> > Hadron Quark wrote:
>>> >> The Ghost In The Machine <ew...@sirius.tg00suus7038.net> writes:
>>> >>
>>> >> >
>>> >> > OK, dumb question. What exactly is the problem here?
>>> >>
>>> >> There is no problem : I asked posters to discuss how a developer
>>> >> decides which tools and "choice process" a developer would use to
>>> >> determine how best to develop a Linux GUI app. Ideally it would be WM
>>> >> independent but that's not really possible if you want to make use of
>>> >> certain libraries such as GTK or QT. The choice of one of these then
>>> >> influences the language you use.
>>> >>
>>> >> I never said it had to be cross platform.
>>> >>
>>> >> The zealots have tried to pull the thread down like a tiger after a baby
>>> >> gazelle.
>>> >
>>> >
>>> > You go with whatever libraries the customer wants? Or in the case of no
>>> > customer, whatever you want? So cross platform is not desired, sorry I
>>> > screwed that up, but I don't see how that changes anything. The "choice
>>> > process" is no different from developing a Windows GUI app. Customers
>>>
>>> It is SO different it is not funny.
Cross-platform is a candidate for inclusion into the
project requirements. If it is not required, it is
obviously droppable from the requirements list, and the
developer can then do whatever he feels necessary to meet
the rest of the requirements.
On Linux, cross-platform isn't too difficult, though one
has to exercise some care. I'll admit I've still not
mastered autogen, automake, genconf, libtool, etc. etc.,
though tools such as Glade-2 assist nicely in setting up
project templates.
>>>
>>> > have specific requirements, and you develop to those requirements.
>>>
>>> Johnny wants to create his own market. There are no customer specs
>>> YET. There might be later down the road - lets hope he picks the right
>>> WM to integrate with then eh? Otherwise he's fucked.
>>>
>>> > You're pretending like these problems don't exist for Windows or other
>>>
>>> They dont. Not to the same extent.
>>>
>>> > OSes. The "choice process" is the same regardless of OS, WM, or
>>> > anything else. You can't have a "choice process" if you've already
>>> > limited yourself to C/C++ at the get go.
>>> >
>>>
>>> This is totally bogus.
>>>
>>> --
>>> Do not dry clean.
>>
>> Why though? Shouldn't the first choice after deciding what you're going
>> to do, be what language to use? So you pick the language that works
>> best right?
>>
>
> if you are only comfortable with one language maybe. I'm familiar with
> both c and c++.
Whoopee. That's two. Have you forgotten about Java, C#,
Python, Tcl, Ruby, Gambas Basic, Bourne shell, and Perl? :-)
>
> The first thing to decide is which APIs you need to get the "job done"* and
> then see which bindings are available for that API.
Actually, the first thing to decide is what needs doing; one
can then search for/design with the APIs to accomplish that task.
>
> * : and "job done" means a lot of things. Functional completeness,
> compatability with clients on site work, future safe knowledge
> investment etc etc. Its not a trivial choice at all.
>
Except on Windows, where one simply uses the Windows APIs thoughtfully
provided by the vendor. :-)
--
#191, ewi...@earthlink.net
Linux sucks efficiently, but Windows just blows around
a lot of hot air and vapor.
cc
If you are comfortable with only one language there is no choice. If
you're only comfortable with two then there's not much more choice. Are
you telling me you can't pick up another language when you need to?
> The first thing to decide is which APIs you need to get the "job done"* and
> then see which bindings are available for that API.
>
> * : and "job done" means a lot of things. Functional completeness,
> compatability with clients on site work, future safe knowledge
> investment etc etc. Its not a trivial choice at all.
>
> --
> <posix> this guy _is_ crazy
> <stargazer> posix: from the looks of Enlightenment he's on LSD
> <posix> LSD is nothing compared to what this guy's on..
> -- Seen on #Unix
The first thing for the rest of us to decide is which APIs you need, as
per the original question. All I'm pointing out is that you made then
initial choice of c/c++, where some of us would have choosen a better
solution. But you didn't want an easy answer, so you made initial
choices that make the problem harder. You say the API is not a trivial
choice, but neither is the programming language.
Bob Hauck
<qadro...@geemail.com> wrote:
> Bob Hauck <postm...@localhost.localdomain> writes:
>
>> On Thu, 19 Oct 2006 01:27:01 +0200, Hadron Quark
>> <qadro...@geemail.com> wrote:
>>
>>> Bob Hauck <postm...@localhost.localdomain> writes:
>>>> Use ALSA unless there's some reason to do otherwise.
>>
>>> "use ALSA" .. another person with ZERO clue about systems programming.
>>
>> Another asshole with an agenda.
>
> Oh sorry, I didn't realise you had an agenda too.
My agenda is that I think your response was completely uncalled-for.
I also think that "systems programming" doesn't mean "writing end-user
applications". That falls under "applications programming".
> You guys crack me up : all wind & water and little clue.
>
> "Use ALSA" - lol. Talk about missing the point about all this.
What was the point exactly? You do realize, don't you, that ALSA
includes user-space libraries as well as the kernel device drivers.
<http://www.alsa-project.org/documentation.php#0.9doc>
<http://equalarea.com/paul/alsa-audio.html>
You asked how to "play a tune". I took that to mean you had some short
sounds saved as raw PCM files that you wanted to play. The ALSA
libraries are directly usable for that without too much trouble. If you
meant that you wanted a pre-done multimedia framework, something that
could decode MP3 files and handle threading and timers and so on then
you should have said so.
How you approach these things depends on the application. You don't
need a full multimedia framework to play a couple of beeps, but if you
are writing a sound editor or a game then maybe you do.
You asked an open-ended question, and then proceeded to expound on what
is wrong with all the answers you got. Even the fact that you got lots
of answers is somehow turned into a bad thing. Too many choices or
something.
You are absolutely right that there are lots of ways to do things on
Linux. You are correct that there is no grand unified scheme. Which of
course you knew from the start. Criticizing that was the whole point of
starting this thread in the first place.
You seem to think this is constructive criticism. It is not. It is
mental masturbation.
You don't like having multiple UI guidelines? Constructive criticism
would be to urge eveyone to adopt some UI guideline you like. Maybe
lend a hand to Freedesktop.
You think there are problems with the toolkits? Constructive criticism
would be to point out flaws in Qt or GTK or SDL that you think ought to
be fixed, or even to send in a patch.
What you're doing is basically just whining that Linux would be a lot
better off if only it were controlled by some corporation that would
hold your dick for you. That way it would be more like Windows and
everything would be all sweetness and light.
Nobody cares about that, it is irrelevant fantasy. All it does is label
you as a clueless individual with worthless opinions.
JEDIDIAH
...which is how game programmers in real life approach
this problem.
I think quark here pretended to be an "award winning"
FPS programmer at one point.
> for its part has the drawback that it wants to take over
> the entire screen.
[deletia]
>> Oh my god. You really think its that simple? Jesus. No wonder so many
>> home brew linux apps look like shit.
>
> It's worse than that. Poor design at this layer will cause
> major headaches later. One ideally would abstract the problem away.
> Gtk in particular has a Gdk sublayer, and also a Cairo sublayer;
> Cairo not only allows for subpixel rendering but also allows for
> SVG, PDF, and bitmap generation.
>
> However, one might still want to abstract away the
> widgeting subproblem so as to substitute something else
> later, such as something within Qt, raw X, or Win32.
[deletia]
--
If you think that an 80G disk can hold HUNDRENDS of |||
hours of DV video then you obviously haven't used iMovie either. / | \