Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6206 > unrolled thread

Recommendations for building a multi-platform desktop application.

Back to article view | Back to comp.programming

Contents

  Recommendations for building a multi-platform desktop application. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-07 11:37 -0800
    Re: Recommendations for building a multi-platform desktop application. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2016-01-07 21:24 +0100
      Re: Recommendations for building a multi-platform desktop application. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-07 18:02 -0800
        Re: Recommendations for building a multi-platform desktop application. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2016-01-08 09:30 +0100
          Re: Recommendations for building a multi-platform desktop application. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-13 10:25 -0800
            Re: Recommendations for building a multi-platform desktop application. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2016-01-13 21:20 +0100
            Re: Recommendations for building a multi-platform desktop application. Öö Tiib <ootiib@hot.ee> - 2016-01-14 02:57 -0800
    Re: Recommendations for building a multi-platform desktop application. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-07 21:55 +0000
      Re: Recommendations for building a multi-platform desktop application. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-07 18:01 -0800
        Re: Recommendations for building a multi-platform desktop application. Jacob Sparre Andersen <sparre@nbi.dk> - 2016-01-08 10:05 +0100
        Re: Recommendations for building a multi-platform desktop application. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-08 19:14 +0000
        Re: Recommendations for building a multi-platform desktop application. Öö Tiib <ootiib@hot.ee> - 2016-01-09 04:09 -0800

#6206 — Recommendations for building a multi-platform desktop application.

Hopefully, enough people still visit this newsgroup to get some 
meaningful responses...

I've been an enterprise software engineer for the last 10 years, working 
on the server side of web based applications.  I'm good at designing 
such applications, but I've got an idea that is more suited to the 
desktop space (it needs to be able to work offline, for one thing).

I use a Mac personally, but if my idea takes off, I'd like to make sure 
it can be "easily" ported to Windows and Linux with native idioms.

It is already going to be a bit of a learning curve for me to build a UI 
on the Mac, but I think I can do it.  In any case, what I'm hoping to do 
is to build the stuff that isn't UI specific in a common code-base. I'm 
thinking that C++ might be the language of choice for this common layer, 
and then provide bindings for Swift and C# when it comes time to make 
the code portable.

I'm actually familiar with C++, but have never done anything with Swift 
or C#.  I have done Java UI programming before, but I don't think 
that'll suit my purpose here.

So, what I'm hoping for is either confirmation that I'm thinking about 
this correctly, or suggestions on other technology I may be unaware of.

Thanks,
Daniel.

[toc] | [next] | [standalone]

#6207

On 2016-01-07 20:37, Daniel Pitts wrote:
> I use a Mac personally, but if my idea takes off, I'd like to make sure
> it can be "easily" ported to Windows and Linux with native idioms.
>
> It is already going to be a bit of a learning curve for me to build a UI
> on the Mac, but I think I can do it.  In any case, what I'm hoping to do
> is to build the stuff that isn't UI specific in a common code-base. I'm
> thinking that C++ might be the language of choice for this common layer,
> and then provide bindings for Swift and C# when it comes time to make
> the code portable.
>
> I'm actually familiar with C++, but have never done anything with Swift
> or C#.  I have done Java UI programming before, but I don't think
> that'll suit my purpose here.
>
> So, what I'm hoping for is either confirmation that I'm thinking about
> this correctly, or suggestions on other technology I may be unaware of.

There are basically only two major alternatives: Qt and GTK. GTK has 
plain C interface which makes it possible to use with some more decent 
language than C/C++. Qt is somewhat more difficult to use with a 
languages other than C++. Both have comparable performance and enjoy 
target platform hardware acceleration. GTK deploys native look-and-feel. 
Qt is more distant.

On the other hand GTK maintainers keep on doing almost everything to 
discourage users by introducing incompatibilities with each new version. 
Qt has potential licensing problems. Qt supports a wider set of OSes, 
e.g. VxWorks. Both support Windows, Mac, Linux.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#6210

On 1/7/16 12:24 PM, Dmitry A. Kazakov wrote:
> On 2016-01-07 20:37, Daniel Pitts wrote:
>> I use a Mac personally, but if my idea takes off, I'd like to make sure
>> it can be "easily" ported to Windows and Linux with native idioms.
>>
>> It is already going to be a bit of a learning curve for me to build a UI
>> on the Mac, but I think I can do it.  In any case, what I'm hoping to do
>> is to build the stuff that isn't UI specific in a common code-base. I'm
>> thinking that C++ might be the language of choice for this common layer,
>> and then provide bindings for Swift and C# when it comes time to make
>> the code portable.
>>
>> I'm actually familiar with C++, but have never done anything with Swift
>> or C#.  I have done Java UI programming before, but I don't think
>> that'll suit my purpose here.
>>
>> So, what I'm hoping for is either confirmation that I'm thinking about
>> this correctly, or suggestions on other technology I may be unaware of.
>
> There are basically only two major alternatives: Qt and GTK. GTK has
> plain C interface which makes it possible to use with some more decent
> language than C/C++. Qt is somewhat more difficult to use with a
> languages other than C++. Both have comparable performance and enjoy
> target platform hardware acceleration. GTK deploys native look-and-feel.
> Qt is more distant.
>
> On the other hand GTK maintainers keep on doing almost everything to
> discourage users by introducing incompatibilities with each new version.
> Qt has potential licensing problems. Qt supports a wider set of OSes,
> e.g. VxWorks. Both support Windows, Mac, Linux.
>

I feel like you misunderstood.  I'm hoping to create the UI in the 
language specific to the platform, but have the UI backed by common 
library code written in, say, C++.

I'm not expecting to write-once-run-anywhere the UI portion.

[toc] | [prev] | [next] | [standalone]

#6212

On 2016-01-08 03:02, Daniel Pitts wrote:
>
> I feel like you misunderstood.  I'm hoping to create the UI in the
> language specific to the platform, but have the UI backed by common
> library code written in, say, C++.

(What is the language specific to the platform?)

Qt is written in C++. GTK is written in C. Both have platform-specific 
portions dealing with the native rendering back-end, e.g. for X11 under 
Linux vs. WinGDI under Windows.

> I'm not expecting to write-once-run-anywhere the UI portion.

Why not? That is the main reason to use such libraries. The GUI and all 
application code I write requires no changes when compiled for Windows 
or Linux. If I designed, say a Windows only application, I would use 
Win32 API.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#6219

On 1/8/16 12:30 AM, Dmitry A. Kazakov wrote:
> On 2016-01-08 03:02, Daniel Pitts wrote:
>>
>> I feel like you misunderstood.  I'm hoping to create the UI in the
>> language specific to the platform, but have the UI backed by common
>> library code written in, say, C++.
>
> (What is the language specific to the platform?)
>
> Qt is written in C++. GTK is written in C. Both have platform-specific
> portions dealing with the native rendering back-end, e.g. for X11 under
> Linux vs. WinGDI under Windows.
Sure, but that's not quite the point.

>> I'm not expecting to write-once-run-anywhere the UI portion.
>
> Why not? That is the main reason to use such libraries.
Which is why I'm not considering such libraries.

> The GUI and all
> application code I write requires no changes when compiled for Windows
> or Linux. If I designed, say a Windows only application, I would use
> Win32 API.

Just because it presents a UI that "functions" on the target platform, 
doesn't mean it plays well with the target platform.  My first target 
platform is OS X, which has specific UXD idioms which are not the same 
as in Windows or Linux.

[toc] | [prev] | [next] | [standalone]

#6220

On 2016-01-13 19:25, Daniel Pitts wrote:
> On 1/8/16 12:30 AM, Dmitry A. Kazakov wrote:
>> On 2016-01-08 03:02, Daniel Pitts wrote:
>>>
>>> I'm not expecting to write-once-run-anywhere the UI portion.
>>
>> Why not? That is the main reason to use such libraries.
> Which is why I'm not considering such libraries.

Let's remember that.

>> The GUI and all
>> application code I write requires no changes when compiled for Windows
>> or Linux. If I designed, say a Windows only application, I would use
>> Win32 API.
>
> Just because it presents a UI that "functions" on the target platform,
> doesn't mean it plays well with the target platform.

It plays incomparably better than any Web-based UI suggested. Of course 
the native API could be better, but they are usually so messy due to 
backward compatibility and low-level abstraction reasons that any 
difference is quite marginal.

> My first target
> platform is OS X, which has specific UXD idioms which are not the same
> as in Windows or Linux.

You said above you didn't want it portable. So if it is OK for you to 
redesign UI for each target, why do you worry about idioms?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#6221

On Wednesday, 13 January 2016 20:25:33 UTC+2, Daniel Pitts  wrote:
> On 1/8/16 12:30 AM, Dmitry A. Kazakov wrote:
> > On 2016-01-08 03:02, Daniel Pitts wrote:
> >>
> >> I feel like you misunderstood.  I'm hoping to create the UI in the
> >> language specific to the platform, but have the UI backed by common
> >> library code written in, say, C++.
> >
> > (What is the language specific to the platform?)
> >
> > Qt is written in C++. GTK is written in C. Both have platform-specific
> > portions dealing with the native rendering back-end, e.g. for X11 under
> > Linux vs. WinGDI under Windows.
> Sure, but that's not quite the point.
> 
> >> I'm not expecting to write-once-run-anywhere the UI portion.
> >
> > Why not? That is the main reason to use such libraries.
> Which is why I'm not considering such libraries.

You did throw baby away with washing water here. The argument that one
can use same GUI design on all platforms is indeed wrong. However it is
*not* the reason why to use same tool for designing things for all the 
platforms. Qt is simply a good tool.

> 
> > The GUI and all
> > application code I write requires no changes when compiled for Windows
> > or Linux. If I designed, say a Windows only application, I would use
> > Win32 API.
> 
> Just because it presents a UI that "functions" on the target platform, 
> doesn't mean it plays well with the target platform.

Platform-specific GUI tools don't hold your hands to follow most 
modern local idioms any more than Qt does. It is sometimes 
outright opposite however. Those sometimes push you towards
outdated style. Example: Microsoft own programs had icons and
buttons with 32 bit colors already year 2000. MFC in Visual Studio
("Microsoft Foundation Classes" C++ GUI Framework) supported
only 4 bit color icons/buttons up to 2008. Devs to hack somehow
themself and ignore the tools for 8 years to achieve that app does 
not look like made 1994. That was likely one reason why MS started
to lose its market (was almost full windows at 2000) to other OSes. 

So *you* have to know what and how you do in GUI down to 
slightest detail and no tool will help you there but platform-specific
tools tend to try to screw or limit you while Qt is neutral and so
offers anything what is only possible to show on screen.   

>  My first target platform is OS X, which has specific UXD idioms
> which are not the same as in Windows or Linux.

The Objective-C based GUI runs fine on OS X (since Mac has lot of
power) but it can be quite sluggish, or not smooth and eat battery
on iOS. Qt uses OpenGL to render GUI and is perceivably more 
efficient than recent "native" Apple-made crap by my experience.

[toc] | [prev] | [next] | [standalone]

#6208

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:

> Hopefully, enough people still visit this newsgroup to get some
> meaningful responses...
>
> I've been an enterprise software engineer for the last 10 years,
> working on the server side of web based applications.  I'm good at
> designing such applications, but I've got an idea that is more suited
> to the desktop space (it needs to be able to work offline, for one
> thing).

Just a note to say that offline does not mean without a server.  I
wanted a quick UI to do something the other day and the fastest method
was in a web page to a local server.  That can be a normal server
(e.g. Apache, LightHttpd etc) or one built from a specific language like
nodejs, Haskell or PHP.

Making the browser the UI can simplify things a lot though it's not
always suitable.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#6209

On 1/7/16 1:55 PM, Ben Bacarisse wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>
>> Hopefully, enough people still visit this newsgroup to get some
>> meaningful responses...
>>
>> I've been an enterprise software engineer for the last 10 years,
>> working on the server side of web based applications.  I'm good at
>> designing such applications, but I've got an idea that is more suited
>> to the desktop space (it needs to be able to work offline, for one
>> thing).
>
> Just a note to say that offline does not mean without a server.  I
> wanted a quick UI to do something the other day and the fastest method
> was in a web page to a local server.  That can be a normal server
> (e.g. Apache, LightHttpd etc) or one built from a specific language like
> nodejs, Haskell or PHP.
>
> Making the browser the UI can simplify things a lot though it's not
> always suitable.
Yeah, I've considered this as well.  The thing is that I'm also going to 
want integration with iOS devices at least (and probably Android/Windows 
at some point).  I feel like a web-server is high overhead for a 
native-feeling App.

[toc] | [prev] | [next] | [standalone]

#6213

Daniel Pitts wrote:

> The thing is that I'm also going to want integration with iOS devices
> at least (and probably Android/Windows at some point).  I feel like a
> web-server is high overhead for a native-feeling App.

I don't think you need to fear the overhead.  The cost of moving bits
over HTTP can be insignificant compared to rendering a user interface.

But I'm not sure if it is possible/allowed to run a web-server on iOS,
Android and Windows for phones.

I think your choice of targets limits the list of available languages to
C and C++, but you should check if there are other options.  (I would
like to suggest Ada for the backend, but I haven't heard of an Ada
compiler targeting iOS.)

Greetings,

Jacob
-- 
"It ain't rocket science!" - Well, some of it is!

[toc] | [prev] | [next] | [standalone]

#6215

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:

> On 1/7/16 1:55 PM, Ben Bacarisse wrote:
>> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>>
>>> Hopefully, enough people still visit this newsgroup to get some
>>> meaningful responses...
>>>
>>> I've been an enterprise software engineer for the last 10 years,
>>> working on the server side of web based applications.  I'm good at
>>> designing such applications, but I've got an idea that is more suited
>>> to the desktop space (it needs to be able to work offline, for one
>>> thing).
>>
>> Just a note to say that offline does not mean without a server.  I
>> wanted a quick UI to do something the other day and the fastest method
>> was in a web page to a local server.  That can be a normal server
>> (e.g. Apache, LightHttpd etc) or one built from a specific language like
>> nodejs, Haskell or PHP.
>>
>> Making the browser the UI can simplify things a lot though it's not
>> always suitable.
> Yeah, I've considered this as well.  The thing is that I'm also going
> to want integration with iOS devices at least (and probably
> Android/Windows at some point).  I feel like a web-server is high
> overhead for a native-feeling App.

I don't know what's available on all your target platforms, but overhead
should not be an issue.  Many languages provide an API that can act as a
simple server -- in nodejs it's about three lines of code -- and, since
your data loops though the local interface, it won't impose any
noticeable delay.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#6216

On Friday, 8 January 2016 04:01:48 UTC+2, Daniel Pitts  wrote:
> On 1/7/16 1:55 PM, Ben Bacarisse wrote:
> > Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
> >
> >> Hopefully, enough people still visit this newsgroup to get some
> >> meaningful responses...
> >>
> >> I've been an enterprise software engineer for the last 10 years,
> >> working on the server side of web based applications.  I'm good at
> >> designing such applications, but I've got an idea that is more suited
> >> to the desktop space (it needs to be able to work offline, for one
> >> thing).
> >
> > Just a note to say that offline does not mean without a server.  I
> > wanted a quick UI to do something the other day and the fastest method
> > was in a web page to a local server.  That can be a normal server
> > (e.g. Apache, LightHttpd etc) or one built from a specific language like
> > nodejs, Haskell or PHP.
> >
> > Making the browser the UI can simplify things a lot though it's not
> > always suitable.
> Yeah, I've considered this as well.  The thing is that I'm also going to 
> want integration with iOS devices at least (and probably Android/Windows 
> at some point).  I feel like a web-server is high overhead for a 
> native-feeling App.

Then Qt (that Dimitry A. Kazakov already suggested) is most perfect.
Same C++ application layer for all 5 named platforms (OSX, Windows, 
Linux, iOS and Android). Qt is designed around easiness of binding
application layer to UI layer and runs nicely on those platforms.

Parallel UI design for so different platforms will take lot of effort.
What is designed for Android phone feels crippled on iPad and like
nonsense on desktop and exactly same is true in opposite direction.

It will be extremely annoying to switch between 5 or more UI design
tools and UI binding codes. Each will have issues and odd quirks. 
Qt however means just one tool and same binding layer for all platforms.
It will feel like wonder after you have tried that other option. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web