Discourse.APK



  • I was setting up my new phone yesterday, which involved spending a lot of time in the Google Play Store, when on an idle whim, I thought I would see if there's a Discourse App...

    So this might be worth a try, maybe it's better than using a browser...

    Unfortunately, it's not better...

    It basically lets you enter your login details, then crashes on launch every time you try to use it...

    Hmm, I wonder if it's just me...

    Yeah, I guess not...


  • sockdevs

    Is there a reason all your screenshots look like they're being viewed through rose-tinted specs? :stuck_out_tongue:



  • Is there any way to blame the Chrome team?



  • @RaceProUK said:

    Is there a reason all your screenshots look like they're being viewed through rose-tinted specs? :stuck_out_tongue:

    Yes.


  • sockdevs

    @tar said:

    Yes.

    …so…erm…why that thing I said?



  • @RaceProUK said:

    …so…erm…why that thing I said?

    Why is there a reason? ;P



  • WONTFIX ASDESIGNED


  • :belt_onion:

    Damn it! They were faster, I was planning on making one and just releasing it out of the blue.

    But that requires effort...



  • @Onyx said:

    But that requires effort...

    If you implement one dialogue box and then throw an exception, you'd already be at parity with this version...


  • :belt_onion:

    I got... not far...



  • @tar said:

    Twilight

    Urbandroid Team

    f.lux does a similar job for PCs:

    f.lux makes your computer screen look like the room you're in, all the
    time. When the sun sets, it makes your computer look like your indoor
    lights. In the morning, it makes things look like sunlight again.

    Tell f.lux what kind of lighting you have, and where you live. Then forget about it. f.lux will do the rest, automatically.



  • Yeah, my current preference is as follows:

    • F.lux on Windows
    • Redshift on Linux
    • Twilight on Android
    • (I Don't Know's on third?)


  • It must be new, I looked for a Discourse app a few months ago and there was nothing.

    Why the hell release a broken app to the play store? Just post it on google code github or something and let someone else finish it before publishing it.


  • :belt_onion:

    And how the hell is it built? It obviously doesn't use the JSON "API" our bots here use, meaning that even they have no GUI they are all actually likely to be more advanced than something that got released in Play store.

    *sigh* I should really get that damned API up to a working state one of these days...



  • Even their website is broken


  • :belt_onion:

    No 504s? That is not the Discourse way!

    Edit:

    Like that. See? That's the Discourse way.



  • @hungrier said:

    "If you are interesting"



  • Rules me out, then :'(


  • Banned

    This is weird, that app has nothing to do with us, they should not be using our name and logo like that its confusing



  • You ought to be able to get Google to remove it from the store. It seems abandoned in any case...


  • :belt_onion:

    I was intending on adding something onto it once I developed mine (if I ever actually get around to it). Probably a Q or Qt, in Qt's grand tradition of just adding Q to whatever and calling it quits.

    I'd ask for permission first in any case. It's common fucking courtesy if nothing else. And I'd imagine there might be a trademark on the logo / name?



  • So, Disqourse?


  • :belt_onion:

    @Zecc said:

    Disqourse

    So stealing that :laughing:

    Also, possible logo (currently used as testing bot's avatar):

    (probably not, Digia might come after me :P)

    Now I actually want to do some work on it...



  • Pretty cool logo. How did you make it?


  • :belt_onion:

    You mean the idea or the technique?

    It's Discourse logo replacing "Qt" on Qt logo:

    As for the actual drawing bit: Found Qt logo in svg format, chucked it into Inkscape, traced Discourse logo and stuck it on using the perspective tool. Pretty basic stuff, really.



  • I did notice what the idea was.

    I meant the software, sorry.

    Edit: Inkscape has a perspective tool? :mindblown:



  • Your image is broken, btw.

    Access denied. Error 1011, wtf?

    Oh, hotlinking not allowed.


  • :belt_onion:

    @Zecc said:

    Edit: Inkscape has a perspective tool? :mindblown:

    It's a bit weird, but it works. Mostly. Sometimes goes haywire. Actually had to copy all of my stuff into a new document at times to get it working again.

    @Zecc said:

    Oh, hotlinking not allowed.

    Whoops. Will fix.



  • Make sure it includes a widget to see if you have any notifications. In addition to actual Android notifications.


  • :belt_onion:

    I think that bit might have to be Java :unamused:

    From what I skimmed online only Java apps can be widgets on Android. There might be a way to get it working but I found no concrete examples yet.



  • @Onyx said:

    From what I skimmed online only Java apps can be widgets on Android.

    You can't use the NDK to build widgets? Huh...

    Then again, I've never tried to build an Android widget.

    Maybe you can build a java stub class which loads a DLL and calls into it? That's how an almost-all-C++ application would work....

    EDIT: here's the entirety of my java code template for an NDK app:

    // Autogenerated java launcher stub for libfw.
    package ##NS##;
    import org.libsdl.app.SDLActivity;
    
    public class ##CLASS## extends SDLActivity {
        static {
            System.loadLibrary("##BIN_TARGET##");
        }
    }
    
    

  • :belt_onion:

    @tar said:

    You can't use the NDK to build widgets? Huh...

    I think the problem is wrapping them into the launcher. Do note that my "Android development" was limited to "Hit deploy. Test. Works.". I never got deep into the Android specific stuff.

    @tar said:

    Maybe you can build a java stub class which loads a DLL and calls into it? That's how an almost-all-C++ application would work....

    Sounds reasonable. Though I don't know shit about Java so...

    In any case, the first step would be to finish the API bit. It's more boring than hard (shitloads of boilerplate so that it can get integrated with QML properly), though I have some architectural doubts still, too.


  • Banned

    As long as the general consumers do not get confused and think we released/endorsed this, we are fine.


  • sockdevs

    True, but there's also the issue of failure to defend the trademark. Not that that means anything needs to be done, but it's something to bear in mind ;)


  • Banned

    Yeah working on that now:

    https://meta.discourse.org/t/discourse-android-app-on-github/24812/3


  • :belt_onion:

    From meta.d topic:

    It loads browser with discourse in it with all basic android functions. It has no connection with android through the notification system, but it lets you use Discourse as app. If you have an idea how to connect notifications please share. Google Cloud Messaging?

    Well, that explains a lot.



  • @sam said:

    In half an hour he created application just for him

    @Onyx said:

    Well, that explains a lot.

    It really does


  • :belt_onion:

    Hmmm... I might've solved my dilemma... And since I think we don't have much left to say on the original topic (and there's always Jeffing if this gets out of hand)...

    When I pull JSON for topic / posts there's a lot of extra info passed along with it beside the post content alone: usernames, avatar URLs and such. Pretty much everything needed to render the post as you see it on here. Now, I wanted to separate that data at least a bit to avoid duplication / messy classes, but constructing some kind of User object for every user in the topic seems like a bit of an overkill.

    I am, of course, an idiot. A bare struct should do the job and there shouldn't be that much of an overhead. If I just make it a pointer and keep a list of all posters in a Topic object that Post objects can reference...

    I might be overthinking this. Any thoughts?

    For semi-decent documentation of relevant JSON bits see: http://what.thedailywtf.com/t/the-unofficial-discourse-api-docs/8908



  • What the JS does is it uses the users in the topic response to fill up a user ID -> BasicUser object mapping. (BasicUser = just enough info to render an avatar)


  • :belt_onion:

    I did think about a Poster class (BasicUser in your case, I guess that's what Discourse calls it internally?) but I still feel like it might be an overkill. After all, do I need any methods in it?

    Unless there's a good case where I might want to use the BasicUser outside a post I'm fine with it. None comes to mind atm though. But if there is a case for it do tell, I'd like to avoid rewriting a bunch of code if I can. I'm just paranoid about how many objects I juggle around since I want this thing to be as memory-efficient as possible. I intend to use it on mobile, after all.

    As an aside, I still don't understand why the user data wasn't wrapped in a separate object in JSON. Hell, the only difference in the template would be either a single block ({{#user}} ... {{/user}}) or just using {{user.property}} instead of {{property}}.

    Edit: For the pendants: I know I can have methods in a struct. I'd inherit any additional class from QObject though, so I can tie it into the meta-object system as needed, so there's some overhead. Then again, I can skip the inheritance bit, I guess.



  • Not entirely sure what you're asking, but ISTR coming to the conclusion that updating all the local user data from the topic json was the only reasonable option for keeping that info in sync.

    Here's what I got stuck on:

    • Marking posts as read: This may not be relevant if qt has events for when objects scroll onto/off screen, otherwise you're looking at either mucking about with incredibly inelegant viewport monitoring or breaking one of the fundamental features of Discourse.
    • Displaying posts: Raw discomdbbhtm is not really acceptable for human (or even programmatic) consumption; you're probably going to need to render cooked html. Can qt efficiently load hundreds of browser-controls on a page, or will you need to render the entire post stream as a web view? Parse html to native controls? Think about how you're going to actually render posts before wasting your time on anything else.

  • :belt_onion:

    @Buddy said:

    Marking posts as read

    There are signals (events) that emit on movement start / stop that I intend to use to start checking visible posts. I'm planning to create a ListModel out of posts and put them into a ListView which has an itemAt(x, y) method that I can use to detect which post is in the current viewport. The exact vertical positioning / tolerance will be a bit of a challenge, but then again wasn't it for Discourse as well? ;)

    @Buddy said:

    Displaying posts

    I can actually, in worst case scenario, use the same JS Markdown parser if I want to work from raw as Discourse does (QtQuick includes fully functional v8). My plan is to use the cooked content though. There will be some challenges with that though. I have WebKit rendering engine available within Qt but I'll try to avoid (ab)using it.

    Qt can actually render HTML up to a reasonable level and should be able to handle the limited HTML set that Discourse allows inside posts (I did not check the full list, if there is one?). The only sticking points are some of the HTML5 bits, with <aside> being the thing that worries me the most. That's the reason I'm actually considering using the JS Markdown parser if needed. That way I can just parse the raw and handle quotes and any other potentially problematic elements by using my own templates.

    @Buddy said:

    Can qt efficiently load hundreds of browser-controls on a page

    The intent is to use native Qt(Quick) controls. They won't render offscreen, and will use OpenGL rendering when applicable. Memory usage is something that will have to be benchmarked of course. Luckily, we have a perfect topic for that somewhere around here... :P



  • Also, notifications are pretty much out of the question; you might think you could have a webservice polling on the message bus and pushing notifications back out to the users, but think about how that's gonna scale. What will you do if there's 100 users? 100 webservices? Or are you going to implement polling from the mobile? Do you have a strategy for minimizing battery use?

    Obviously, none of these problems are insurmountable; what I'm trying to say here is: Don't worry about the api; that's the easiest bit. (Although, are you saving posts locally for offline viewing? If so, you're going to have a COMPLAIN! of a time tracking jeffed posts/topics. Still not impossible though)

    @Onyx said:

    Qt can actually render HTML up to a reasonable level and should be able to handle the limited HTML set that Discourse allows inside posts (I did not check the full list, if there is one?). The only sticking points are some of the HTML5 bits, with <aside> being the thing that worries me the most.

    Well, there's a list; not sure how complete it is (ISTR some code running in a post-whitelist context (onebox maybe?), and some other code adding temporary special-cases to the whitelist (poll-plugin maybe?)):
    https://github.com/discourse/discourse/blob/1.9.0/app/assets/javascripts/discourse/lib/markdown.js#L307


  • :belt_onion:

    @Buddy said:

    Or are you going to implement polling from the mobile? Do you have a strategy for minimizing battery use?

    I'd be happy to connect to that Discourse WebSocket... oh, right, no such thing :stuck_out_tongue:
    My browser polls for notifications when I use Discourse. Same problems apply. If a better solution presents itself, sure, I'll implement it. But for now, polling it is. I do, of course, intend to include options for what happens when the app is in background: polling off and interval settings. When app is open and in focus I see no problem in polling just as the browser does.

    And no, I don't intend to run a server of my own to push notifications. I don't want the responsibility of having to handle that data, and I don't intend to make money on this. This is a learning experience for me: I'm learning more about Qt, QML and mobile apps in general. I'm happy to release it for free and offer as much support as I can, but nothing beyond that.

    @Buddy said:

    Don't worry about the api; that's the easiest bit.

    I need the API to feed the data to any GUI I make first. And I'd rather work with actual data (especially from this place, with all it's abuse of HTML, Unicode and XSS attempts) than just mocking something myself. I also intend to release it as open source for anyone else to use. I want to present something usable to any potential users, not a cobbled together mess.

    Is the API comparatively easy? Sure. Most of it is, as I said, boring boilerplate. But boring boilerplate that's badly assembled will bite me in the ass sooner or later, and I'd rather avoid a visit to the proctologist if at all possible. So that's where my focus currently is, because I can't even move far along without it. The first step is getting a simple bot running using the API. When that works well enough I'll start playing with GUI stuff.

    @Buddy said:

    Well, there's a list

    Cheers. At a glance everything outside <aside> should be fine. Again, I'll cross that bridge when I get to it. Who knows, might get better HTML5 support with next Qt version. Might not. Time will tell.


    Filed under: Yes, Vivaldi, proctologist is a word, What are you using for spellchecking anyway? WebKit?



  • And are you going to allow auth other than user/pass? You could get a session by loading the /login page in a browser control and letting the user log in. It's not really a page (just redirects back to the home page with the login overlay showing), but it could theoretically be usable, even on mobile:


  • :belt_onion:

    Looks reasonable. I didn't yet poke around OAuth stuff yet so I can't tell how easy or hard it would be to get it working "properly" without messing with the browser control. Preferably I'd avoid it so you're not bound to a GUI if you want to use it for something else, but it's an option in any case.



  • Nah, you should load /site/settings.json instead:

    http://what.thedailywtf.com/site/settings.json

    
    enable_local_logins: true,
    allow_new_registrations: true,
    enable_google_logins: false,
    enable_google_oauth2_logins: true,
    enable_yahoo_logins: true,
    enable_twitter_logins: true,
    enable_facebook_logins: true,
    enable_github_logins: true,
    enable_sso: false,
    
    flush_timings_secs: 10,
    
    max_image_size_kb: 3072,
    max_attachment_size_kb: 1024,
    authorized_extensions: ".jpg|.jpeg|.png|.gif",
    ga_universal_tracking_code: "UA-9122028-2",
    category_style: "bar", // bar, box, bullet
    


  • contact_email: "apapadimoulis@inedo.com",
    censored_words: "elgiu|belgium",
    maximum_backups: 3,
    

  • Discourse touched me in a no-no place

    I think you meant to write this:

    contact_email: "apapadimoulis@inedo.com",
    censored_words: "■■■■■|■■■■■■■",
    maximum_backups: 3,
    

    (■TFY)


  • Grade A Premium Asshole

    @Onyx said:

    sigh I should really get that damned API up to a working state one of these days...

    You're trying to hit a moving target. Good luck. ;-)


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.