Discourse native application

Software Native
1

Is there interest in a haiku native application for the forum?
Personally I am sick of the mobilification of the forum that seems to slowly creep in, and antifeatures like breaking smiles, and emojis by replacing them with png…

Anyhow, It seems to be possible to make an application using the official api. Is there any interesting in people actually using it though? If most people just use these forums on their phone or on other OS it would likely not be worth it. (And for my part I don’t know any other discourse forums, though they certainly exist)

(The auth part seems to demand an api key though, but i couldn’t find if there is a seperate user auth for the api… wierd)

1 Like
2

Turning the text into emojis can be disabled, it is just a checkbox away in the forum settings. It would still be possible to insert emojis using the icon in the toolbar.

So, if that’s your only complaint… Should we remove automatically turning text into emojis?

  • Yes, disable turning text into emoji images automatically
  • No, I like the smiley faces

0 voters

3

My complaint also is that they are not emojis at all, but rather PNG images. They usually loose what I was actually trying to express, and now with us having the full range of Noto Emoji it is really annoying that this is the only part of Haiku that has completely different smileys for everything.

4

My very personal opinion is: If it is fun for you, do it. I know some othe forums with Discourse. And I understand you being annoyed by mobilification. But I doubt that there is much use for it.

I think the following forums are Discourse-driven, too:

intfiction.org about text adventures

freegamedev.net about FLOSS games playing and developing

And of course many others which I don’t know.

5

As someone who has looked for years into dedicated forum apps (as a browser alternative) the biggest problem with Discourse is that messages are coded as Markdown. Markdown (specifically CommonMark Markdown) requires an HTML5 passthrough because it is merely a shorthand notation of HTML5 and not a specific subset. You never know what tags will find their way into a Markdown encoding.

If all the messages could be converted into a superset of BBCode, it would be easier for the forum app to parse and the HTML5 engine could then be discarded as excessive. Not a moment before, though. Since HTML5 is a hard requirement for the current system, you might as well just finish WebPositive because nothing less will presently do.

6

I’m very interested in a native Discourse application.
I’m mostly here using Librewolf on Solaris or using my phone,because Discourse only displays a blank white page in QtWebKit-based browsers on Haiku.
It’s insane how high the browser requirements are nowadays,for something as simple as a forum.
Would be cool to workaround that whole webapp nonsense using a native Haiku application that integrates great with the OS.

Markdown parsing does not at all require HTML5,by the way.
Yes,Markdown has a feature that allows embedding any custom HTML,but it’s probably not the best idea to allow that for user-generated content anyway as malicious Javascript and things like that could be integrated easily this way.
If you don’t need HTML-embedding,there are many libraries in different languages for parsing Markdown,that’s totally not a problem.

1 Like
7

It should be possible to just not render the raw HTML tags. MD4C is a Markdown parser library in C with optional inline HTML support.

8

re:Insane Requirements for a Browser

Discourse’s database code can only be accessed by a ReST interface. That means the user-facing code basically is a custom app writren in JavaScript already. That actually is ideal for writing a custom app because that means the inrerface is fully documented.

1 Like
9

Yes,that makes writing a native application really easy compared to server-side-generated PHP pages like phpBB.
On the other hand,having server-side-rendered content that doesn’t strictly require Javascript and works just fine in Internet Explorer 8 or something like that probably wouldn’t require writing a native application in the first place.

10

Looks like slightly more than half the voters would like this disabled.

1 Like
11

Now it’s tied.

12

It’s not closed

13

I really don’t see the harm in disabling the auto-emoji feature.

People that really like inserting emojis (like me :stuck_out_tongue_winking_eye:) will still be able to do it, and quite easily.
At the same time, people that like to type smileys (like me ;P) will be able to do it easily also.

The convenience of ones does not need to hamper the ability of others.

On top of that, the supposed convenience really just benefits the keyboard-centric type of users on a desktop or laptop, that try to avoid touching the mouse as much as possible.
Ironically, my unproven suspicion is that the majority of this users just prefer to craft their own smileys, and when faced with this automation they just shrugh and think “Oh well, another trendy thing I have to swallow”.
Meanwhile, the more mouse-centric users (like me ^-^¡) just don’t care having to click on an icon to insert an emoji.
On a mobile device the situation gets pretty equal for both, or even reverses, as sometimes is easier to insert a recently used emoji from the emoji menu than to type some smileys on those multi level on-screen keyboards.

As a side note, wouldn’t it be funny and irritating at the same time that the emoji set were extended with a series that represented as images a good chunk of this classic typed smileys?
Better not to give ideas…

Regarding the matter of a native application for the forum, it will be nice to have such an important part of the project having a first-class place of its own.
On the other hand, every time that I have used as independent apps things that were initially conceived to be used inside a browser, the experience feels a bit disjointed, can’t middle click to open a link or a thread in a new tab… things like that.
I guess it all depends in how good the integration between this app and WebPositive ends up being. In the end, it can be kind of like having the forum opened in its own browser window, but using less resources.

BTW, how will this app be called?
Discourse?
Discourse+?
Positive Discourse?

If the Discourse name can’t be used for whatever reason, I propose calling it Bikeshed, we already have the icon for it.
This icon will just need a slight change of the colours, don’t you think?
Hmmm… what colours can we paint the bikeshed? :thinking:

1 Like
14

Bikeshed-o-Matic, given the forum icon used. :stuck_out_tongue:

2 Likes
15

how will this app be called?

Discourse? :man_shrugging:

1 Like
16

But how to look into the forum, i am not in haiku? And you can not use everythere a free software to look into the forum (at work as example). I does not understand this discussion at all, we have many other, more importand things to do.

But if one have fun to generate such a program, why not, but the forum should be as it is.

17

Having a native application doesn’t mean that the webapp will go away.
We can have a native application only for Haiku where we get the native look and feel and good integration with the OS,and still have the webapp that works everywhere you have Firefox.

2 Likes
18

I am corrected: There IS a use case for this. But is it really an improvement, making things better for the end user of the forums?

OK, this is just about semantics, but: Won’t the native application be a sort of webapp?

19

An internet app but not a webapp.

3 Likes