[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

Recommendations for building a multi-platform desktop application.

Daniel Pitts

1/7/2016 7:38:00 PM

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.
11 Answers

Dmitry A. Kazakov

1/7/2016 8:24:00 PM

0

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-...

Ben Bacarisse

1/7/2016 9:56:00 PM

0

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.

Daniel Pitts

1/8/2016 2:02:00 AM

0

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.

Daniel Pitts

1/8/2016 2:03:00 AM

0

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.

Dmitry A. Kazakov

1/8/2016 8:31:00 AM

0

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-...

Jacob Sparre Andersen

1/8/2016 9:06:00 AM

0

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!

Ben Bacarisse

1/8/2016 7:15:00 PM

0

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.

Öö Tiib

1/9/2016 12:09:00 PM

0

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.

Daniel Pitts

1/13/2016 6:25:00 PM

0

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.

Dmitry A. Kazakov

1/13/2016 8:20:00 PM

0

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-...