A lot of people didn’t like the hamburger menu (see here and elsewhere in this thread). It should be easy to disable, just a line of css (see here). Also, the hamburger menu is still there, so disabling the bottom nav bar still lets you use the interface the same way you are used to.

It is a checkbox in the community creation form. Similarly, the auto-discovery of new communities is also a checkbox on the admin/federation page.

wjs018 [is] now admin

Hey! That’s me! I just wanted to provide some thoughts on this release…

Most of my dev time for this release went into backend api stuff. Specifically, this point:

Automatically-updating Swagger docs to ease frontend development

So, most of the regular users probably won’t really notice (unless it breaks your favorite mobile app). However, I just wanted to send some thanks to both rimu and freamon for the work that they did in finishing this up. Also, to thank the cadre of mobile app/frontend developers that provided input, tested changes, and pointed out problems along the way. It was a lot of work that is completely transparent to most people, at least it hopefully is transparent.

Going forward, the newly schematized api should be much easier for developers interacting with it, and we shouldn’t be introducing breaking changes at this point. I wouldn’t yet call the api complete or mature, but it is at least a stable base from which we can expand, and the most common types of interactions should be implemented at this point.

The other feature I wanted to highlight is this one:

Federate flair changes properly

This was actually a lot of work for such a short bullet point. Basically, we rewrote the post flair system so that it federated out as part of the community in the activitypub messages passed between instances. What this means for users is that communities located on piefed 1.2+ instances should have their full flair list visible on remote instances, regardless of whether the flair has been used or not. For example, if a community mod changes the name of a flair, it will automatically be updated on every instance and every post that it was attached to as that flair edit is federated out.

This work also laid the groundwork for post flair being interoperable with what lemmy is planning to do with their 1.0 release. Their work is still ongoing, so it might yet change, but when we were restructuring how flair was implemented on our end, we tried to make it look like what they are currently planning so that it can hopefully be a seamless integration when lemmy 1.0 is released.

Admins: I also added a function for remote communities that lets you “fix up from remote” located near the bottom of the sidebar. Basically, if you have a remote community on your instance that has some extraneous pre-1.2 flair hanging around that could use some cleaning up, then you can hit that button and it should phone back home to the community’s home instance and kind of reset things for you to bring everything in sync.

Thanks! Fixing that in compact mode was on my to do list for quite some time.

Off the top of my head, some of the cross post aggregation that piefed does in the web frontend was only very recently (like literally yesterday) added to the api. Post flair is another that was only just added to the api within the past week or so, so I don’t expect it has seen a lot of use yet in apps. Lots of the features around feeds and topics aren’t included yet. And, most annoyingly for me, is that most of the notification types are not returned in the api yet. So, you can end up in a scenario where the api will tell you that you have X unread notifications, but since some of those notification types might not be defined yet in the api, you can only interact with a subset of them.

We are working on it!

I think the limited part of this is that there are still lots of things that you can only do in the web ui that aren’t exposed to the api yet. It isn’t rate limited.

There is an api by which things like mobile apps can be used with piefed.

Piefed has an open issue to look at improvements to the ranking/scoring algorithms. So, we are open to improvements on that end if there are suggestions.

That’s great! Feel free to share over at !piefed_css@piefed.social.

there’s no difference between both themes

Do you mean Tile and Wide Tile? They are going to look the same on mobile, yeah. The actual difference between them is that Wide Tile will use a lot more horizontal screen real estate for users with very widescreen monitors (which would obviously not be the case on mobile). It might make sense to make the Wide Tile button just disappear on smaller screens.

text hints become useless because my phone doesn’t have a cursor

This bugs me too! I don’t really have a good solution though. Some things that have popups but aren’t links will work if you tap them. Sometimes tapping and holding on a link will cause the popup to appear. It’s not consistent, but I don’t have a better idea of how to do this either.

As for your question at the top, about multiline titles in either of the tile views, try adding this snippet to your custom user css in your settings:

#masonry .item .masonry_info .row .col-8 p {  
    white-space: normal;  
}  

Piefed’s web UI tries to be responsive to the screen size it is being displayed on. So, as the screen size changes, so does the layout. To see what I mean, it is easiest If you are on a desktop. I primarily use firefox, so that is what these instructions are for, but other browsers have similar functionality.

First, open up a piefed community (like !piefed_meta@piefed.social) and then hit ctrl+shift+m to go into an emulated mobile view. This lets you shrink and expand the size of your emulated screen. You can make it big like a desktop, wide like a landscape tablet, or tall and narrow like a phone. As you grow and shrink your “screen”, you should see elements of the page change layout, shape, disappear or appear in response. You can also click the “Responsive” part of the bar displayed at the top of the browser and change it to some pre-defined device sizes.

The sidebar where the “Create Post” button normally lives on desktop goes away, down to the bottom of the page as your screen width shrinks. So, to have a way to be able to make a post without scrolling all the way to the bottom, we stick it in an Options dropdown along with several other things that get hidden as the UI needs to become more dense (like layout and filters). This might not be the optimal solution, but we are always open to ways to improve the UI. It is probably an area where we could use the most input from regular (non-technical) users.

Ah, yeah…it’s there, it is just sitting at a score of -135, so it is probably being hidden by your filters. On the Blocks & Filters page of your user settings, there is a threshold at which comments and posts are hidden automatically. Feel free to adjust this to whatever you desire. In this case, it would need to be something less than -135.

A moderator deleting a chain of comments shouldn’t really be simply due to downvotes. It can be a useful tool when you have a huge chain of comments with people going wildly off topic and getting nasty with one another. I have only had to use it once before when a comment chain between two individuals devolved into personal attacks against one another.

After some testing, I found that the checkbox you are referring to does not actually delete all replies in a chain when it is checked by a non-moderator. Instead, it only deletes all the replies made by you in the chain. I submitted a fix to change the wording for this checkbox in the next version of piefed so that it clarifies this behavior.

Cool! Glad to see the focus on actual good science. I work professionally in Biologics drug development, but more on the manufacturing side than the research/discovery side. It can be hard to find actually good discussion forums that don’t just get filled up with armchair experts that focus only on a couple illicit active ingredients.

This is my primary way of using piefed. There are a number of improvements for mobile-sized screens coming in the 1.2 update.

Alright, I did some testing, and this feature is not quite working as intended. Here are the results of my testing:

• A normal user (non-mod or admin) checks this box:

  • The user’s comment will be deleted, but…
  • it will not delete the comments of other users
  • The normal user’s other comments down the chain will also be deleted.

• A mod or admin checks this box:

  • All the comments in the chain are deleted as expected

Yeah, I remember the discussion about this feature and it was only intended for mods. Seems like a permissions check isn’t working right.

It all works (I wrote it), but that issue is about consolidating some code for the future. We know there are going to need to be some changes made to the implementation of post flair once we start testing lemmy interoperability. So, that issue is essentially saying let’s write all the flair code in one place so that it’s easier to change in the future instead of having flair code duplicated between the api side and the web ui side of the piefed.

At the moment it would not be interoperable, but that is something we are planning to change once we can start testing it. Last time I checked, the lemmy test server wasn’t yet running a build that had post flair yet. As soon as it is, we would want to make sure that Activitypub messages we send have the same structure.

Upholstery fabric is thicker than most fabric you would use for garments. It is used for furniture, like couches, so it needs to be pretty durable. It is a bit more expensive though, so YMMV depending on how expensive your local fabric store is.

As for doing flay lay, that is just what works best for the types of products I am shooting these days. It is kind of nice in that backgrounds are super easy. I usually shoot against a vinyl, patterned backdrop on the table (I got mine from Ink and Elm). One thing it does limit though is the types of props I can use. Lots of stuff looks great in a picture…but not necessarily from the top down.